Wednesday, 2015-11-11

*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC00:05
*** sjolley <sjolley!sjolley@nat/intel/x-qmqkimkimnnbxpie> has quit IRC00:11
*** Jefro <Jefro!> has quit IRC00:32
*** Jefro <Jefro!> has joined #yocto00:34
*** dvhart <dvhart!~dvhart@> has joined #yocto00:36
*** seebs <seebs!~seebs@> has joined #yocto00:42
*** bluelightning <bluelightning!> has joined #yocto00:43
*** bluelightning <bluelightning!> has quit IRC00:43
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto00:43
*** kscherer <kscherer!~kscherer@> has quit IRC00:49
*** Jefro <Jefro!> has quit IRC00:50
*** stwcx <stwcx!~stwcx@> has quit IRC00:57
*** sjolley <sjolley!~sjolley@> has joined #yocto00:59
*** dvhart <dvhart!~dvhart@> has quit IRC01:01
*** fledermaus <fledermaus!~vivek@> has quit IRC01:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC01:05
*** sameo <sameo!samuel@nat/intel/x-ipdeywcspvimxynw> has quit IRC01:08
*** Jefro <Jefro!> has joined #yocto01:22
*** Jefro <Jefro!> has quit IRC01:27
*** ndec <ndec!~ndec@linaro/ndec> has quit IRC01:38
*** ndec <ndec!~ndec@linaro/ndec> has joined #yocto01:41
*** paulg <paulg!> has quit IRC01:53
*** bananadev <bananadev!~bananadev@> has joined #yocto02:06
*** paulg <paulg!> has joined #yocto02:12
*** paulg <paulg!> has quit IRC02:23
*** armpit <armpit!~akuster@> has quit IRC02:59
*** stwcx <stwcx!> has joined #yocto03:01
*** ntl <ntl!> has quit IRC03:08
*** Jefro <Jefro!> has joined #yocto04:17
*** Jefro <Jefro!> has quit IRC04:46
*** redengin <redengin!~redengin@2601:600:9200:7ab0:1d4f:a9cb:9457:d3b0> has quit IRC04:57
*** redengin <redengin!~redengin@2601:600:9200:7ab0:f97c:715f:8089:213d> has joined #yocto04:58
*** AndersD <AndersD!> has joined #yocto04:59
*** armpit <armpit!~akuster@2601:202:4000:1239:b99e:8fcb:e922:8a29> has joined #yocto05:03
*** dreyna4529 <dreyna4529!> has quit IRC05:13
*** RP <RP!> has joined #yocto05:23
*** sno <sno!> has joined #yocto05:28
*** [Sno] <[Sno]!> has quit IRC05:31
*** _dv_ <_dv_!> has joined #yocto05:36
*** dv__ <dv__!> has quit IRC05:37
*** qknight <qknight!> has quit IRC05:46
*** LostInTheForest is now known as Amynka05:47
*** hundeboll <hundeboll!> has quit IRC05:49
*** AndersD <AndersD!> has quit IRC05:58
*** stefans_ <stefans_!stefans@nat/intel/x-tofxrexrpbzterjs> has joined #yocto06:07
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC06:09
*** Mike1 <Mike1!~mike@> has joined #yocto06:24
*** pohly <pohly!> has joined #yocto06:34
*** hamis_lt_u <hamis_lt_u!~irfan@> has joined #yocto06:43
*** frsc <frsc!> has joined #yocto06:59
*** blueness_ <blueness_!> has quit IRC07:01
*** hundeboll <hundeboll!> has joined #yocto07:05
*** hundeboll <hundeboll!> has joined #yocto07:05
*** frsc <frsc!> has quit IRC07:06
*** frsc <frsc!> has joined #yocto07:06
*** Mike1 <Mike1!~mike@> has quit IRC07:23
*** t0mmy <t0mmy!> has joined #yocto07:31
*** bananadev <bananadev!~bananadev@> has quit IRC07:36
*** egavinc <egavinc!> has joined #yocto07:40
*** bananadev <bananadev!~bananadev@> has joined #yocto07:41
*** loggerbo1 <loggerbo1!~todor@> has joined #yocto07:42
*** Rallis <Rallis!> has quit IRC07:42
*** loggerbox <loggerbox!~todor@> has quit IRC07:43
*** evanp_ <evanp_!evan@nat/intel/x-mzqwogrsczritwpj> has joined #yocto07:43
*** Rallis <Rallis!~chris@> has joined #yocto07:43
*** jmpdelos <jmpdelos!> has quit IRC07:43
*** jmpdelos <jmpdelos!> has joined #yocto07:43
*** tismith <tismith!~toby@> has quit IRC07:43
*** evanp <evanp!~evan@> has quit IRC07:44
*** rZr <rZr!~RzR@unaffiliated/rzr> has quit IRC07:44
*** tismith <tismith!~toby@> has joined #yocto07:45
*** tasslehoff <tasslehoff!~Tasslehof@> has joined #yocto07:47
*** RzR <RzR!~RzR@> has joined #yocto07:49
*** jku <jku!jku@nat/intel/x-aezmwpmmggafvoub> has joined #yocto07:50
*** jku is now known as jku_07:50
*** sno <sno!> has quit IRC07:50
*** drou <drou!> has joined #yocto07:51
drouhi guys07:52
*** tasslehoff <tasslehoff!~Tasslehof@> has quit IRC07:52
droui created an image recipe for my raspberry pi but i don't have any perl module. i just did a IMAGE_INSTALL_append = " perl"07:53
droui thought i would have a lot of perl modules as it seems there is a lot in the perl recipe07:54
*** Rallis <Rallis!~chris@> has quit IRC07:54
*** Rallis <Rallis!> has joined #yocto07:57
drouanother thing is i have a lot of errors at each build:
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC08:01
*** townxelliot <townxelliot!~ell@> has joined #yocto08:01
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto08:03
*** csanchezdll <csanchezdll!> has joined #yocto08:07
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto08:12
mckoangood morning08:15
*** bambule__ <bambule__!5ddcc61d@gateway/web/cgi-irc/> has joined #yocto08:20
*** drou| <drou|!52e867a5@gateway/web/freenode/ip.> has joined #yocto08:21
*** drou <drou!> has quit IRC08:22
*** roccof <roccof!> has joined #yocto08:23
*** bambule__ <bambule__!5ddcc61d@gateway/web/cgi-irc/> has quit IRC08:26
jku_drou|: IMAGE_INSTALL is about packages, not recipes: a recipe can build multiple packages and installing one of those packages does not mean all of them are installed08:27
*** fl0v0 <fl0v0!> has joined #yocto08:27
drou|jku_: ok, so how can i get the appropriate package ? eg perl-module-socket08:31
*** Biliogadafr <Biliogadafr!> has joined #yocto08:31
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:33
jku_drou|: appending exactly that should work (in a production setting your perl script recipe should of course depend on it instead)08:34
drou|hum, i need to have a perl.bbappend that RDEPENDS on this particular module, right?08:35
jku_drou|: alternatively "perl-modules" should give you all perl modules that can currently be built08:35
drou|it tells nothing provies perl-modules, it is the same for perl-module-socket08:37
*** ant_work <ant_work!> has joined #yocto08:37
*** Tenhi_ <Tenhi_!~tenhi@> has joined #yocto08:38
*** LocutusOfBorg1 <LocutusOfBorg1!~LocutusOf@> has joined #yocto08:40
jku_drou|: is this when you do IMAGE_INSTALL_append = " perl-module-socket" ?08:42
drou|no, i thought it was better to have a recipes that RDEPENDS on this, instead of appending the IMAGE_INSTALL with this module. but in fact, it is working08:44
*** sno <sno!> has joined #yocto08:48
DatGizmoMorning, is there a way to do an 'addtask' depending on a machinoverride?08:48
joshuaglYocto blog doesn't mention 2.0/Jethro release - where's the best place to link to for that info? Surely not the mailing-list thread?08:48
jku_drou|: yeah, depending is "better". It shouldn't be perl that depends on the module though, it should be the package that contains script that actually requires module-socket08:49
drou|jku_: that is exactly what i did before, i did a RDEPENDS_${PN}_append = " perl-module-socket" but it didn't help. cant figure out why08:54
*** balister_ <balister_!> has joined #yocto08:54
*** balister__ <balister__!> has joined #yocto08:54
*** Jay7 <Jay7!> has quit IRC08:55
drou|maybe this is something related to the lot of errors log i get08:56
*** Crofton <Crofton!> has quit IRC08:56
*** Jay7 <Jay7!~jay@> has joined #yocto08:57
*** Crofton|work <Crofton|work!> has quit IRC08:57
jku_ drou| those seemed like broken configuration -- maybe double check conf/bblayers.conf ?08:59
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has joined #yocto09:00
drou|jku_: yes, but it looks good:
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:05
*** bluelightning <bluelightning!> has joined #yocto09:05
*** bluelightning <bluelightning!> has quit IRC09:05
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:05
jku_drou|: I believe BB_PATH isn't what you think... it's literally the PATH variable used when the environment is initialized09:05
jku_you can't use it to build BBLAYERS09:06
bluelightningmorning all09:09
drou|hi bluelightning09:11
drou|jku_: so i need to put the BBPATH variable to my build directory?09:13
*** sameo <sameo!samuel@nat/intel/x-zmqagtjjqyptolxa> has joined #yocto09:13
jku_drou|: I'd just try setting BBLAYERS with full paths09:14
drou|i get it, BBPATH is ok, but the bblayers paths are not09:14
jku_that's how it looks to me09:15
*** jonathanmaw <jonathanmaw!> has joined #yocto09:18
*** RagBal <RagBal!> has quit IRC09:23
*** Rootert <Rootert!> has quit IRC09:23
*** diego_r <diego_r!> has joined #yocto09:24
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has quit IRC09:29
*** drou <drou!> has joined #yocto09:31
*** JaMa <JaMa!> has joined #yocto09:38
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has joined #yocto09:44
*** abelal <abelal!~quassel@> has quit IRC09:48
*** abelal <abelal!~quassel@> has joined #yocto09:49
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has quit IRC09:51
*** tasslehoff <tasslehoff!~Tasslehof@> has joined #yocto09:51
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has joined #yocto09:53
*** RagBal <RagBal!> has joined #yocto09:55
*** Rootert <Rootert!> has joined #yocto09:55
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-mijxtxatmcblbbtb> has joined #yocto09:58
*** khem <khem!~khem@unaffiliated/khem> has quit IRC09:58
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto10:02
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-mijxtxatmcblbbtb> has left #yocto10:02
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has quit IRC10:03
*** pidge_ <pidge_!> has joined #yocto10:04
*** hanthings <hanthings!~nandor@> has quit IRC10:04
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has joined #yocto10:06
*** pidge <pidge!> has quit IRC10:06
*** hanthings <hanthings!~nandor@> has joined #yocto10:21
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has quit IRC10:23
*** RP <RP!> has quit IRC10:25
snokhem: seems there is a philosophical problem wrt. ldap dependency (eg. for samba 4)10:25
snoit might lead to a consensus discussing it qickly instead of shooting mails around over days10:26
snosame for sysvinit/lsb init scripts10:27
*** hanthings <hanthings!~nandor@> has quit IRC10:28
*** RP <RP!> has joined #yocto10:28
snoRP: I managed the Perl6 recipes - thanks for your guidance10:28
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has joined #yocto10:35
*** rburton <rburton!> has joined #yocto10:36
*** yann|work <yann|work!~yann@> has joined #yocto10:37
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has quit IRC10:43
xerentsay that I have a layer that adds support for the machine "foo", and I want to make another layer that just changes a few things in the local.conf of that layer, but otherwise changes nothing. can I keep "foo" as the machine name in the new layer?10:43
xerentmore specifically, I want to build for the same machine but change some DISTRO_FEATURES10:43
*** yann|work <yann|work!~yann@> has quit IRC10:46
xerentor am I confusing layers with machines here10:46
bluelightningwell, a layer providing support for a machine shouldn't be touching DISTRO_FEATURES10:50
bluelightningDISTRO_FEATURES is something that's intended to be set from a conf/distro/distroname.conf inside a distro layer10:51
bluelightning(if you're doing things properly)10:51
bluelightningthis allows you to easily swap out the machine support should you need to in future and keep the rest of your configuration10:51
xerentwell I want to build for the same machine target but change a few distro features, I guess make two distros for the same machine10:53
xerentdistro features are being set from platform/foo/local.conf at the moment10:53
xerentwhich maybe wrong then?10:54
bluelightningthere should be just one local.conf under your build directory... you might very well have a template in your distro layer10:54
bluelightninglocal.conf is intended to just select the machine, distro and set local paths; most of the time if you want to set anything more than that it should go into the distro configuration (or if it's specific to providing support for the machine itself, and not about how you're using that machine, then the machine configuration file)10:56
xerentso even if I fixed this I'd still have to edit the local.conf in order to select the other distro10:57
xerentso I'd still need a hack that swapped out local.conf files depending on what distro I wanted to build10:57
*** yann|work <yann|work!> has joined #yocto11:00
xerentwhich is kind of a bummer, really11:01
xerentif I want to build one image version with wayland and another with x11 I can't do that without adding a hack editing my local conf11:01
xerentor did I miss anything?11:01
*** hanthings <hanthings!~nandor@> has joined #yocto11:05
rburtonxerent: sure you can, i do that all the time.  bitbake core-image-sato core-image-weston builds an x11-based image and a wayland image in the same bitbake run.11:06
rburtonyour just need to have both x11 and wayland in distro_features11:06
xerentthe issue is that I can't have both11:06
rburtonwhy not?11:06
xerentbecause of conflicts in my BSP, and also because of space concerns11:07
xerentadding x11 as a distro features expands the image by 100 MB11:07
rburtonspace isn't a concern, distro features != what goes into the image11:07
xerentfunny how the image grows with the distro_features flag ONLY changing then ;)11:07
rburtonif your wayland image grows by 100m when you turn on x11, you've got stuff in your image which you should remove11:07
rburtonso.. remove it.11:07
xerentok, so it's just the freescale BSP incompatibility issues then11:08
rburtonhave a go at freescale then11:08
xerenti will, and I will probably fail at that11:08
rburtonotavio: meta-freescale can't handle both x11 and wayland distro features at the same time?11:08
*** mckoan is now known as mckoan|away11:09
xerentfor iMX6 target11:09
*** marquiz_ <marquiz_!marquiz@nat/intel/x-fgjvtancildzging> has quit IRC11:09
*** dreyna4529 <dreyna4529!> has joined #yocto11:10
lzmis there a way to set variables matching on a prefix? for instance VARIALBE_pn-bla* = "xxx" would match all pn's starting with bla11:12
rburtonwell, you could do that from an anonymous python block11:12
*** drou <drou!> has quit IRC11:14
*** dreyna4529 <dreyna4529!> has quit IRC11:14
lzmi'm trying to reduce repetition in some of these rules
*** marquiz <marquiz!~marquiz@> has joined #yocto11:17
*** matteo <matteo!~matteo@openwrt/developer/matteo> has joined #yocto11:17
xerentrburton: why aren't all distro features always enabled?11:18
xerentI mean, it doesn't affect image size or anything ;)11:18
rburtonbecause it can11:18
*** Rootert <Rootert!> has quit IRC11:19
*** RagBal <RagBal!> has quit IRC11:19
xerentI will implement a hack as workaround for building two images with different distro features without affecting image size then11:19
xerentthanks for your help!11:19
*** RagBal <RagBal!> has joined #yocto11:33
*** Rootert <Rootert!> has joined #yocto11:33
otaviorburton: it cannot11:36
otaviorburton: well, it will for 2.111:36
otaviorburton: as we will be moving for xwayland11:36
rburtonotavio: what's the problem with enabling wayland and x11 in the same distro?11:39
*** yann|work <yann|work!> has quit IRC11:40
rburtonotavio: poky builds images on the ab with x11 and wayland distro features enabled11:40
*** bananadev <bananadev!~bananadev@> has quit IRC11:41
*** RP <RP!> has quit IRC11:44
*** dv_ <dv_!> has joined #yocto11:44
*** _dv_ <_dv_!> has quit IRC11:45
otaviorburton: the Vivante GPU has support for one or another11:45
rburtonand you can't build both and have the packages be mutually exclusive?11:45
otaviorburton: no; they install the gpu libraries for one or another11:47
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto11:47
rburton(two recipes?)11:47
otaviorburton: what do you mean both and be mutually exclusive?11:47
rburtondriver recipe creates two driver packages, vivante-x11 and vivante-wayland, which conflict with each other as they contain the same files (but with different behaviour)11:48
*** Mike1_ <Mike1_!~mike@> has joined #yocto11:48
rburtonjust surprised that the driver makes you pick11:48
otaviorburton: no; their code is build different as well11:50
*** balister_ is now known as Crofton27111:50
otaviorburton: the headers need different defines11:50
*** Crofton271 is now known as Crofton|work11:50
otaviorburton: it is a disaster ;P11:50
rburtonotavio: yeah so build it twice11:51
rburtonclosed gpu driver in being terrible shock!!11:51
otaviorburton: no; let's say cairo11:51
otaviorburton: it needs different defines for the build11:51
rburtonoh jesus11:51
otaviorburton: yes; I know11:52
*** tasslehoff <tasslehoff!~Tasslehof@> has quit IRC11:54
*** tasslehoff <tasslehoff!~Tasslehof@> has joined #yocto11:59
*** AndersD <AndersD!> has joined #yocto11:59
joshuaglI spent some time trying to untangle it recently12:00
joshuaglit drove me to drink ;-)12:01
* rburton is glad to be gone of EMGD12:01
*** sameo <sameo!samuel@nat/intel/x-zmqagtjjqyptolxa> has quit IRC12:01
otavioI was checking mesa with fbdev EGL; JaMa was kind to point me to the discussion showing it has been removed.12:02
otavioThe question is: is there a replacement/12:02
* nrossi is glad the chips he deals with don't even have framebuffers :)12:02
*** jku <jku!> has joined #yocto12:02
*** fledermaus <fledermaus!> has joined #yocto12:02
*** jku_ <jku_!jku@nat/intel/x-aezmwpmmggafvoub> has quit IRC12:03
*** RP <RP!> has joined #yocto12:12
drou|does anyone know if there is a simple command line that allows to send an email using gmail?12:19
otaviodrou|: I use ssmtp12:26
drou|otavio: thanks, i'll take a look at it12:27
drou|otavio: is there any existing recipe for this?12:32
*** tsramos <tsramos!~tsramos@> has joined #yocto12:33
*** tasslehoff <tasslehoff!~Tasslehof@> has quit IRC12:34
*** Noor_ <Noor_!~quassel@> has quit IRC12:36
otavioI thought you were refering to the host12:37
*** Noor <Noor!~quassel@> has joined #yocto12:37
*** hamis_lt_u <hamis_lt_u!~irfan@> has quit IRC12:39
*** realBigfoot <realBigfoot!~realBigfo@> has joined #yocto12:40
*** RP <RP!> has quit IRC12:43
*** RP <RP!~richard@> has joined #yocto12:46
fmeerkoetterhi, i am using systemd/journal on a meta-raspberrypi based yocto image.12:46
fmeerkoetteri've enabled systemd support via12:46
fmeerkoetterDISTRO_FEATURES_append = " systemd"12:46
fmeerkoetterVIRTUAL-RUNTIME_init_manager = "systemd"12:47
fmeerkoetterDISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"12:47
fmeerkoetterthe resulting image works fine12:47
*** tasslehoff <tasslehoff!~Tasslehof@> has joined #yocto12:47
fmeerkoetterbut i noticed that there are still klogd/syslogd running on the resulting system12:47
fmeerkoetterboth started as a systemd unit12:47
fmeerkoetteri wonder if there is a good reason for that12:47
fmeerkoettershouldn't journald be sufficientß12:48
*** drou| <drou|!52e867a5@gateway/web/freenode/ip.> has quit IRC12:50
*** jku <jku!> has quit IRC12:53
t0mmyfmeerkoetter: To enable systemd, I think you also need to add this line VIRTUAL-RUNTIME_initscripts = ""12:54
fmeerkoettert0mmy: it is enabled12:54
fmeerkoetteri am only wondering why klogd/syslogd are still running on the resulting image12:55
t0mmyfmeerkoetter: Otherwise maybe, It is possible that klogd/syslogd are added by a recipe dependency, check recipes you used.12:57
*** silviof <silviof!> has quit IRC13:02
*** vmeson <vmeson!> has quit IRC13:03
*** silviof <silviof!~silviof@> has joined #yocto13:03
*** silviof <silviof!~silviof@unaffiliated/silviof> has joined #yocto13:03
*** jku <jku!jku@nat/intel/x-euatcehwojpzzzrp> has joined #yocto13:10
*** thaytan_ <thaytan_!> has joined #yocto13:13
*** thaytan <thaytan!> has quit IRC13:15
*** Rootert <Rootert!> has quit IRC13:18
*** RagBal <RagBal!> has quit IRC13:18
xerentotavio: thanks for the info on the vivante driver :) I can manage with a workaround enabling distro features for one OR the other (x11 vs wayland)13:22
*** RagBal <RagBal!> has joined #yocto13:22
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has joined #yocto13:22
*** seebs_ <seebs_!> has joined #yocto13:22
*** Rootert <Rootert!> has joined #yocto13:23
*** seebs <seebs!~seebs@> has quit IRC13:23
*** cbzx <cbzx!> has joined #yocto13:36
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has quit IRC13:36
*** kscherer <kscherer!~kscherer@> has joined #yocto13:36
*** vmeson <vmeson!~rmacleod@> has joined #yocto13:37
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has joined #yocto13:42
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has quit IRC13:48
*** ueni <ueni!~ueni@> has joined #yocto13:50
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has joined #yocto13:54
*** klno <klno!~klno@> has joined #yocto13:56
*** thaytan_ is now known as thaytan13:57
*** lamego <lamego!~jose@> has joined #yocto14:03
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has quit IRC14:05
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has joined #yocto14:07
*** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC14:08
*** abelal <abelal!~quassel@> has quit IRC14:08
*** jchonig <jchonig!~quassel@> has quit IRC14:08
*** psnsilva <psnsilva!~psnsilva@> has quit IRC14:08
*** nemunaire <nemunaire!~nemunaire@> has quit IRC14:08
*** arfoll <arfoll!~arfoll@> has quit IRC14:08
*** ueni <ueni!~ueni@> has quit IRC14:10
*** ueni <ueni!~ueni@> has joined #yocto14:10
*** ueni <ueni!~ueni@> has quit IRC14:12
*** abelloni <abelloni!~abelloni@> has quit IRC14:13
*** ueni <ueni!~ueni@> has joined #yocto14:15
*** silviof <silviof!~silviof@unaffiliated/silviof> has joined #yocto14:16
*** abelal <abelal!~quassel@> has joined #yocto14:16
*** jchonig <jchonig!~quassel@> has joined #yocto14:16
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto14:16
*** nemunaire <nemunaire!~nemunaire@> has joined #yocto14:16
*** arfoll <arfoll!~arfoll@> has joined #yocto14:16
*** yann|work <yann|work!> has joined #yocto14:17
*** ueni <ueni!~ueni@> has joined #yocto14:17
*** ueni <ueni!~ueni@> has joined #yocto14:18
*** tasslehoff <tasslehoff!~Tasslehof@> has quit IRC14:19
*** DatGizmo <DatGizmo!> has quit IRC14:20
*** cbzx <cbzx!> has quit IRC14:20
*** Mike1_ <Mike1_!~mike@> has quit IRC14:26
*** RP <RP!~richard@> has quit IRC14:27
*** RP <RP!> has joined #yocto14:30
*** raykinsella781 <raykinsella781!~rkinsell@> has joined #yocto14:34
*** damien_l <damien_l!> has quit IRC14:34
*** dgm816 <dgm816!~dgm816@unaffiliated/orkim> has quit IRC14:36
*** dgm816 <dgm816!~dgm816@unaffiliated/orkim> has joined #yocto14:38
*** DatGizmo <DatGizmo!> has joined #yocto14:46
*** ant_work <ant_work!> has quit IRC14:47
*** madisox <madisox!> has joined #yocto14:53
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2bea:f279:59ff:fe64:3a8> has quit IRC14:53
*** RP <RP!> has quit IRC14:58
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC15:01
*** raykinsella781 <raykinsella781!~rkinsell@> has left #yocto15:02
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto15:02
*** IvanSB <IvanSB!~IvanSB@> has joined #yocto15:17
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC15:18
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC15:19
*** AndersD <AndersD!> has quit IRC15:21
*** aehs29 <aehs29!~aehernan@> has joined #yocto15:30
*** Mike1_ <Mike1_!~mike@> has joined #yocto15:30
*** Mike1_ is now known as Mike115:31
*** psnsilva <psnsilva!~psnsilva@> has quit IRC15:32
*** psnsilva <psnsilva!> has joined #yocto15:34
*** dreyna4529 <dreyna4529!> has joined #yocto15:35
*** ftonello <ftonello!~quassel@> has quit IRC15:49
*** jku <jku!jku@nat/intel/x-euatcehwojpzzzrp> has quit IRC15:50
*** andyintc <andyintc!arudoff@nat/intel/x-atzmzkggbklanwli> has quit IRC15:54
*** tsramos <tsramos!~tsramos@> has quit IRC15:59
*** berton <berton!~fabio@> has joined #yocto16:01
*** belen2 <belen2!Adium@nat/intel/x-gofhbbhcdytixkhb> has joined #yocto16:02
*** tsramos <tsramos!~tsramos@> has joined #yocto16:02
*** belen1 <belen1!Adium@nat/intel/x-csxbcxfkswykiitf> has quit IRC16:03
*** RP <RP!~richard@> has joined #yocto16:13
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto16:13
*** caiortp <caiortp!~inatel@> has joined #yocto16:14
*** grma_ <grma_!> has joined #yocto16:14
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC16:14
*** DarkKnight_ <DarkKnight_!> has joined #yocto16:14
*** anselmolsm <anselmolsm!anselmolsm@nat/intel/x-cxyntcngfigoyxoi> has joined #yocto16:15
*** seezer_ <seezer_!> has joined #yocto16:15
*** erbo_ <erbo_!> has joined #yocto16:15
*** tf <tf!> has joined #yocto16:16
*** zeddii_home_ <zeddii_home_!> has joined #yocto16:16
*** LocutusOfBorg1 <LocutusOfBorg1!~LocutusOf@> has quit IRC16:16
*** otavio_ <otavio_!~otavio@debian/developer/otavio> has joined #yocto16:17
*** akuster <akuster!~akuster@2601:202:4000:1239:b99e:8fcb:e922:8a29> has joined #yocto16:17
*** erbo <erbo!> has quit IRC16:17
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC16:17
*** armpit <armpit!~akuster@2601:202:4000:1239:b99e:8fcb:e922:8a29> has quit IRC16:17
*** zeddii_home <zeddii_home!> has quit IRC16:17
*** tf_ <tf_!> has quit IRC16:17
*** grma <grma!> has quit IRC16:17
*** zeddii_home_ is now known as zeddii_home16:17
*** DarkKnight <DarkKnight!> has quit IRC16:17
*** seezer <seezer!quassel@quassel/developer/seezer> has quit IRC16:17
*** abelloni <abelloni!~abelloni@> has joined #yocto16:20
*** marek_ <marek_!> has joined #yocto16:22
marek_hi all16:22
marek_I'm trying to compile external kernel module but need to pass some defines to module. I do it manually in Makefile by adding: ccflags-y :=, is there way in yocto to specify something like that (EXTRA_OEMAKE maybe?)16:23
*** benjamirc <benjamirc!~besquive@> has joined #yocto16:24
*** frsc <frsc!> has quit IRC16:27
*** TobSnyder1 <TobSnyder1!> has quit IRC16:31
*** pidge__ <pidge__!~pidge@> has joined #yocto16:31
*** grma_ is now known as grma16:31
*** pidge_ <pidge_!> has quit IRC16:34
*** adtec_ <adtec_!> has joined #yocto16:36
snokhem: around?16:37
adtec_Hi, I have a question regarding linux kernel mainline recipes.  Is this the correct channel?16:38
*** pidge__ <pidge__!~pidge@> has quit IRC16:40
bluelightningmarek_: EXTRA_OEMAKE += "ccflags-y='value'" should work16:40
bluelightningadtec_: possibly - ask your question and we'll try our best to answer16:41
*** pidge__ <pidge__!~pidge@> has joined #yocto16:43
marek_bluelightning: many thanks it works16:43
bluelightningmarek_: np16:44
adtec_bluelighting:  Thanks, it should be fairly straight forward.  I need to rev my kernel to mainline linux version 4.1.13, but so far I have been unable to figure out the correct source path16:44
*** sgw_ <sgw_!> has quit IRC16:45
adtec_I am able to check out the 4.3 branch using "SRC_URI = "git://;branch=${SRCBRANCH}", where SRCBRANCH = "master" and SRCREV = "${AUTOREV}".16:46
adtec_But how can I fetch a different kernel version based on a commit number?16:47
*** pidge_ <pidge_!~pidge@> has joined #yocto16:47
snoadtec_: IIRC the stable kernels are at git://
snoadtec_: there are branches for the mainained versions, e.g. linux-4.1.y16:48
*** RzR is now known as rZr16:49
adtec_sno:  Would I use "linux-4.1.y" as SRCBRANCH?16:49
*** LocutusOfBorg1 <LocutusOfBorg1!> has joined #yocto16:49
snoadtec_: likely ;)16:49
snodon't nail me on that, but that would my first start16:50
*** pidge__ <pidge__!~pidge@> has quit IRC16:50
adtec_sno:  Thanks, I'll give it a try16:50
marek_bluelightning: hmm sorry I was too fast it's not working :(16:52
*** LocutusOfBorg1 <LocutusOfBorg1!> has quit IRC16:53
marek_I added #ifdef to code and also #warning but define is not defined16:53
snomarek_: bluelightning gives you the way how to pass values to make, when you need to pass from make to c-source, something like EXTRA_OEMAKE += "-DDEFKEY=VALUE"16:55
marek_sno: but this is special makefile becaus eit's building external kernel module16:56
snomarek_: meta-fsl-arm has a special patch for galcore's module makefile and I have adopted the makefile for 8189es module, too16:57
snounless we have access to your source, we don't know anything about the makefile can deal with16:57
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC16:57
*** nerdboy <nerdboy!> has joined #yocto16:58
marek_sno: which recipe exactly in meta-fsl-arm?16:58
*** nerdboy <nerdboy!> has quit IRC16:58
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:58
*** tsramos <tsramos!~tsramos@> has quit IRC17:01
marek_sno: OK, I'll look on that thanks17:02
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-jxckwefooyvehglv> has joined #yocto17:02
*** belen2 <belen2!Adium@nat/intel/x-gofhbbhcdytixkhb> has quit IRC17:03
*** jonathanmaw <jonathanmaw!> has quit IRC17:03
*** IvanSB <IvanSB!~IvanSB@> has quit IRC17:03
*** belen1 <belen1!Adium@nat/intel/x-vshyytucbtpqgybd> has joined #yocto17:03
snois there a way to pick the kernel per image? E.g. creating default image, build full featured kernel - and for recovery image, build downsized one?17:03
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2efb:f279:59ff:fe64:3a8> has joined #yocto17:04
snoI tried to override PREFERRED_PROVIDER_virtual/kernel in - but still using the full featured one17:04
*** sjolley <sjolley!~sjolley@> has quit IRC17:05
*** Jay7 <Jay7!~jay@> has quit IRC17:06
kergothpreferences are global17:07
*** xp190 <xp190!d04149ca@gateway/web/freenode/ip.> has joined #yocto17:07
*** belen1 <belen1!Adium@nat/intel/x-vshyytucbtpqgybd> has quit IRC17:07
xp190Hi, could someone point me in the right direction to add wolf-ssl to my poky image?17:08
*** Mike1 <Mike1!~mike@> has quit IRC17:09
xp190I found the meta-wolfssl layer, but I'm not having any luck adding it into my build17:09
*** marek_ <marek_!> has quit IRC17:09
adtec_sno:  Thanks, that seemed to have done it.17:10
*** Jay7 <Jay7!~jay@> has joined #yocto17:10
benjamirchello, I have a question, how do you fix pidgin's --SSL handshake failed-- when connecting to the lync service?17:12
benjamircis it via re-running
snokergoth: so I have to modify the machine setting for such a change?17:12
*** fl0v0 <fl0v0!> has quit IRC17:13
*** belen1 <belen1!Adium@nat/intel/x-rntljktvfflfnyfn> has joined #yocto17:15
bluelightningbenjamirc: wrong channel I think...17:15
kergothsno: you can't change what gets built on a per image basis, it just wouldn't make sense. the same package feed is used for all images, and what would happen if you 'bitbake image1 image2 image3'? not doable. deciding what recipes get built is a global configuration change, so distro/machine/etc17:16
*** justanotherboy <justanotherboy!mlopezva@nat/intel/x-josmcrawpmyeanon> has joined #yocto17:16
*** IvanSB <IvanSB!~IvanSB@2a01:2000:2000:2efb:f279:59ff:fe64:3a8> has quit IRC17:18
RPIn case anyone is interested the patch I just posted is worth a speed double for "bitbake -p" and a hot cache17:19
kergothwow, nice17:20
RPkergoth: loading the codeparser cache three times in succession was just stupid...17:20
kergothheh, indeed17:21
kergothdidn't realize it got initialized multiple times in a single build17:21
rburtonJaMa: your buildname patch doesn't apply to master17:21
RPkergoth: its as the config gets built by the UI :/17:21
RPkergoth: turns features to the right settings and so on, annoying but kind of understandable17:21
rburtonJaMa: oh you sent a variation which does apply17:22
RPkergoth: I'm still not convinced its right but codeparser reloading is clearly wrong and killing performance so its the low hanging fruit17:22
RP(theory was that a core config reset was cheap I guess)17:23
*** ftonello <ftonello!~quassel@> has joined #yocto17:24
*** Mike1_ <Mike1_!~mike@> has joined #yocto17:24
*** klno <klno!~klno@> has quit IRC17:28
*** ueni <ueni!~ueni@> has quit IRC17:28
*** ueni <ueni!~ueni@> has joined #yocto17:28
*** klno <klno!~klno@> has joined #yocto17:28
snokergoth: doable or not might lead us into a philosophic discussíon - for today it's enought that is not supported17:30
*** maxin <maxin!~maxin@2001:998:22:0:e962:ae54:f825:9bf7> has left #yocto17:30
*** stwcx <stwcx!> has quit IRC17:31
*** benjamirc <benjamirc!~besquive@> has quit IRC17:32
*** sjolley <sjolley!~sjolley@> has joined #yocto17:33
*** var_x <var_x!> has joined #yocto17:35
*** psadro <psadro!~Thunderbi@> has quit IRC17:37
*** seezer_ is now known as seezer17:37
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto17:38
khemsno: yes17:40
*** Biliogadafr <Biliogadafr!> has quit IRC17:40
khemRP: I use bitbake -p often and I tried it17:41
khemseems to be good17:41
*** jku <jku!> has joined #yocto17:45
*** sjolley <sjolley!~sjolley@> has quit IRC17:49
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-jxckwefooyvehglv> has left #yocto17:50
ulf`RP: Does this patch work on top of 2.0? URL?17:52
snokhem: I thought the ldap/samba/lfs discussion could be faster here17:58
bluelightningulf`: yes if you apply it to bitbake;
JaMasomeone building gtk+3 with wayland enabled? here it fails to find wayland-scanner | configure: error: Could not find wayland-scanner in your PATH18:02
var_xwhats the best way to share files between recipes? I'm trying to get the gutenprint recipe working again and it involves copying some natively compiled files from gutenprint-native18:03
JaMavar_x: stage them in sysroot18:04
var_xJaMa: Thanks - Learning this as I go18:05
bluelightningvar_x: ensure the files go somewhere in the sysroot basically - but note that does not mean you should explicitly install them there - install them as normal in do_install into an appropriate path under ${D}, and then they'll be staged from there18:05
*** belen1 <belen1!Adium@nat/intel/x-rntljktvfflfnyfn> has quit IRC18:05
bluelightningvar_x: if the path you're installing under isn't staged (not all are by default) then you can extend that, but that needs to be done properly18:05
*** belen1 <belen1!Adium@nat/intel/x-wiqmkfqizthikjuk> has joined #yocto18:05
bluelightningsee the last lines of this recipe for an example:
bluelightningit's uncommon to need to do that though18:06
* bluelightning recently filed a bug about documenting this properly18:07
var_xbluelightning: Thanks that helps ... do that mean that the native files I need copyed will be on the target sysroot though? I don't need the native files as the end result, gutenprint just needs them for the compiling ... it's not cross compiler friendly :/18:07
*** roccof <roccof!> has quit IRC18:07
bluelightningvar_x: no, you can refer to the native sysroot from a target recipe just fine18:07
var_xaaah gotcha18:08
bluelightningvar_x: see the STAGING_.*_NATIVE variables defined in meta/conf/bitbake.conf18:08
snodifference in optimization between RDEPENDS and DEPENDS - can RDEPENDS be build parallel to requiring recipe (e.g. because RDEPENDS without DEPENDS guides to e.g. script sourcing, perl module using, ...), or does RDEPENDS results in the same strict order as DEPENDS?18:09
bluelightningsno: RDEPENDS just means that it's going to be the packaging tasks of the recipe depending on those of the recipes producing the named packages, as opposed to DEPENDS where do_configure depends on do_populate_sysroot of the mentioned items18:12
snobluelightning: thanks18:13
var_xbluelightning: holy crap - so thats where everything is defined! That will help me so much. If I could kiss you through IRC i would.18:13
bluelightningvar_x: heh, well, I appreciate the sentiment :D18:14
bluelightningvar_x: you may also find bitbake -e | less (with / to search) useful18:14
bluelightningthat'll also pick up things defined elsewhere, since bitbake.conf doesn't define everything (and things defined there can be overridden later)18:15
*** t0mmy <t0mmy!> has quit IRC18:16
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:21
*** benjamirc <benjamirc!~besquive@> has joined #yocto18:27
*** stwcx <stwcx!~stwcx@> has joined #yocto18:29
*** tsramos <tsramos!~tsramos@> has joined #yocto18:29
fmeerkoetterhow can I find out which packages have packageX as a dependency aka. what pulled in a certain dependency?18:29
*** matteo <matteo!~matteo@openwrt/developer/matteo> has quit IRC18:34
*** T0mW <T0mW!> has joined #yocto18:35
*** Jefro <Jefro!> has joined #yocto18:40
T0mWThis is driving me crazy (all nighters and broken coffee machine doesn't help ;), I have a recipe that requires another recipe to fully build before bitbake processes it.  What dependency do I make to hold off the build until the first finishes out?  DEPENDS_${PN} = "blah" doesn't work, do I use RDEPENDS?18:41
*** jku is now known as |18:42
*** | is now known as Guest4686518:42
*** Guest46865 is now known as jku18:43
*** caiortp <caiortp!~inatel@> has quit IRC18:43
rburtondefine fully build18:45
kergothwhat do you mean by fully build?18:45
kergothrburton: :)18:45
*** sjolley <sjolley!~sjolley@> has joined #yocto18:45
*** townxelliot <townxelliot!~ell@> has quit IRC18:46
*** pohly <pohly!> has quit IRC18:46
T0mWkergoth: do_installs should have run to completion.18:46
T0mWthere is a header file which needs to appear in the sysroots, the second recipe needs that to build its binary.18:47
kergoththat's what DEPENDS is for18:47
kergothnearly every recipe sets it..18:48
kergothby default, for anything in DEPENDS, do_configure will depend on their do_populate_sysroot18:48
kergothso we know their files from do_install are available in the sysroots18:48
T0mWDEPENDS / DEPENDS_${PN} in second recipe?18:48
kergothDEPENDS, period18:48
kergoththere is no DEPENDS_${PN}18:48
kergothRDEPENDS is used for binary pcakages, and so is specific to the binary package name18:48
kergothDEPENDS is build time, for the recipe, and so is now18:48
T0mWkergoth: doh, working.  Too much keyboard time and not enough sleep , thanks.18:50
*** belen2 <belen2!> has joined #yocto18:50
* T0mW needs less caffine18:50
*** hugovs <hugovs!~hugo@> has joined #yocto18:57
*** jku <jku!> has quit IRC18:58
*** pidge__ <pidge__!~pidge@> has joined #yocto19:01
*** belen2 <belen2!> has quit IRC19:02
*** pidge_ <pidge_!~pidge@> has quit IRC19:03
*** pidge_ <pidge_!~pidge@> has joined #yocto19:07
*** pidge__ <pidge__!~pidge@> has quit IRC19:08
*** Jefro <Jefro!> has quit IRC19:19
*** berton <berton!~fabio@> has quit IRC19:20
*** AndersD <AndersD!> has joined #yocto19:22
*** Jefro <Jefro!> has joined #yocto19:23
*** hanthings_ <hanthings_!> has joined #yocto19:23
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC19:25
*** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto19:26
*** AndersD <AndersD!> has quit IRC19:28
*** roric <roric!> has joined #yocto19:32
*** berton <berton!~fabio@> has joined #yocto19:34
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC19:42
*** manuel_ <manuel_!~manuel@> has joined #yocto19:46
*** manuel_ <manuel_!~manuel@> has quit IRC19:58
*** Jefro <Jefro!> has quit IRC19:59
*** manuel_ <manuel_!~manuel@> has joined #yocto19:59
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:00
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto20:01
*** Jefro <Jefro!> has joined #yocto20:05
*** jku <jku!> has joined #yocto20:05
*** jku <jku!> has quit IRC20:07
*** cbzx <cbzx!> has joined #yocto20:18
*** drou <drou!52e867a5@gateway/web/freenode/ip.> has joined #yocto20:22
droui'm getting an error in the do_install step of my recipe, it tells i don't have the correct permissions to create a file:
kergothyou have to tell make to install the files into ${D}20:29
kergothfor autotools this is automatic, by setting DESTDIR20:29
kergothfor non-autotools make-based systems, not all of them support such a variable, in which case you'd have to patch it in20:29
drouhere is my recipe: i tried to override the do_install step by adding install -d ${D}${sbindir} but it didnt help20:29
kergothand set EXTRA_OEMAKE appropriately20:30
kergothno, it's make install that's trying to write to the wrong path20:30
kergothinstall -d isn't going to do anything20:30
kergoththat project uses autoconf, but not automake, so it doesn't comply with automake conventions like DESTDIR20:30
*** manuel_ <manuel_!~manuel@> has quit IRC20:30
kergothyou'll have to patch its makefile to prepend $(DESTDIR) to the destination paths, and then pass it in with EXTRA_OEMAKE20:31
drouso basically in my EXTRA_OEMAKE i'll have += "DESTDIR=20:32
drousorry, += "DESTDIR=${D}"20:32
*** hanthings_ <hanthings_!> has quit IRC20:36
*** IvanSB <IvanSB!~IvanSB@> has joined #yocto20:38
kergothactually in this case that part is already handled, since you're inheriting autotools-brokensep . i'd thought at first it was a custom make based setup before i looked at the recipe & source, but it's autoconf, so autotools.bbclass is already passing DESTDIR in do_install20:39
kergothso you just need to patch the makefiel to obey it and you'll be set20:39
*** manuel_ <manuel_!~manuel@> has joined #yocto20:41
*** trip0 <trip0!> has joined #yocto20:44
trip0can anyone explain the meaning of ${prefix} ?20:45
trip0i think it has a different semantic meaning than what CMAKE_INSTALL_PREFIX means20:45
trip0but, cmake.bbclass sets CMAKE_INSTALL_PREFIX to ${prefix} anyway20:46
droukergoth: alright thanks, i'll try to do that20:46
kergothtrip0: prefix is /usr in most systems.20:46
kergothsee bitbake.conf20:47
trip0yep, looking at bitbake.conf now20:47
trip0prefix is not the same as DESTDIR as in "make DESTDIR=/foo/bar install", right?20:47
kergothcorrect. all our target path vars like prefix/bindir/etc are all *relative to* DESTDIR20:48
trip0if prefix is set to /usr, and DESDIR is /foo/bar, a library will install in /foo/bar/usr/lib ...20:48
kergothDESTDIR is an alternate /20:48
trip0okay.  there is a bug in cmake.bbclass then20:48
kergothi think if it wasn't installing files to ${D} in its install, none of our cmake recipes would work at all20:49
*** manuel_ <manuel_!~manuel@> has quit IRC20:49
trip0maybe CMAKE_INSTALL_PREFIX should be set to ${base_prefix} ?20:49
trip0kergoth, perhaps.  this is what it baffles me.  if CMAKE_INSTALL_PREFIX is set to /usr, a system config file would be installed to /usr/etc20:50
*** manuel_ <manuel_!~manuel@> has joined #yocto20:50
trip0they are installing to ${D}, but cmake is appending $(prefix} to every file after that.20:51
*** berton <berton!~fabio@> has quit IRC20:51
trip0so effectively ${D} becomes ${D}/${prefix}20:51
kergoththat does sound wrong20:52
trip0what I'm seeing is that I'm telling cmake to install a systemd unit to /lib/systemd/, but cmake is prepending ${prefix} to that.  so it always gets installed to /usr/lib/systemd20:52
trip0which is wrong20:53
trip0this particular recipe has a post install script that fixes it20:54
trip0I'm guessing a lot of cmake recipies do as well20:54
trip0so fixing cmake.bbclass will break a lot of cmake recipes :(20:55
JaMasno: if only 3 months old...20:55
*** sno <sno!> has quit IRC20:55
*** dreyna4529 <dreyna4529!> has quit IRC20:55
*** justanotherboy <justanotherboy!mlopezva@nat/intel/x-josmcrawpmyeanon> has quit IRC20:58
*** justanotherboy <justanotherboy!mlopezva@nat/intel/x-hrjygmhqcdzgesrb> has joined #yocto20:59
*** manuel__ <manuel__!~manuel@> has joined #yocto20:59
kergothbetter to fix it properly in the class and adjust the recipes to remove their hacks, in that case, i'd think20:59
kergothat least 2.0 is out now, so it could go to master20:59
*** manuel_ <manuel_!~manuel@> has quit IRC20:59
*** manuel__ is now known as manuel_20:59
*** drou <drou!52e867a5@gateway/web/freenode/ip.> has quit IRC21:01
*** benjamirc <benjamirc!~besquive@> has quit IRC21:02
*** JaMa <JaMa!> has quit IRC21:02
trip0kergoth, okay, i'll make the fix and submit to mailing list21:04
*** pidge_ <pidge_!~pidge@> has quit IRC21:05
rburtonnow is the perfect time for that - plenty of time for other layers to catch up21:06
* rburton wonders if we found a new cmake class maintainer21:06
*** yann|work <yann|work!> has quit IRC21:07
* kergoth is currently working through mentor's queue of bits to submit21:07
joshuagltrip0 ♥ cmake21:07
trip0me too21:07
hugovs /quit21:07
*** hugovs <hugovs!~hugo@> has quit IRC21:07
joshuaglyah, that's what I was saying trip0 - why not maintain the class? ;-)21:07
trip0oh, heh.21:08
*** yann|work <yann|work!> has joined #yocto21:10
yann|workI'm puzzled by the use of the arm-poky-linux-gnueabi "triplet", with "poky" in the place of hardware vendor21:12
yann|workdoesn't it already cause problems, with eg. SDL2 expecting "raspberrypi" as vendor for that platform ?21:14
trip0kergoth, patch should go to openembedded-core mailing list?21:14
joshuaglthat's right trip021:16
*** sgw_ <sgw_!~sgw_@> has joined #yocto21:17
trip0thx, joseppc21:17
trip0er joshuagl21:17
*** Mike1_ <Mike1_!~mike@> has quit IRC21:22
kergothyann|work: buildsystems that make assumptions based on vendor are generally broken, or at the least worth beating into shape21:23
*** pohly <pohly!> has joined #yocto21:23
*** manuel_ <manuel_!~manuel@> has quit IRC21:23
joshuaglthat's right trip021:24
joshuaglbah, sorry - I appear to be repeating myself21:24
*** fledermaus <fledermaus!> has quit IRC21:26
*** manuel_ <manuel_!~manuel@> has joined #yocto21:26
trip0patch sent.  let the breakage begin!21:28
*** manuel_ <manuel_!~manuel@> has quit IRC21:29
*** manuel_ <manuel_!~manuel@> has joined #yocto21:30
*** IvanSB_ <IvanSB_!~IvanSB@2a01:2000:2000:2fd5:f279:59ff:fe64:3a8> has joined #yocto21:32
*** IvanSB <IvanSB!~IvanSB@> has quit IRC21:34
*** ant_home <ant_home!~ant__@> has joined #yocto21:35
*** cbzx <cbzx!> has quit IRC21:37
*** benjamirc <benjamirc!~besquive@> has joined #yocto21:38
yann|workkergoth: right, trying to convince the SDL guys ;)21:41
*** pohly <pohly!> has quit IRC21:42
yann|workbut OTOH, putting anything in the vendor field could be seen as broken as well, maybe encouraging some people to use it...21:42
kergothvendor is an arbitrary string, depends on who built the toolchain you're using. it's not necessarily going to tell you anything about the target21:42
*** IvanSB_ <IvanSB_!~IvanSB@2a01:2000:2000:2fd5:f279:59ff:fe64:3a8> has quit IRC21:43
kergothi can see why they might make assumptions based on it given knowledge of particular toolchains, but obviously that logic won't do squat for us, since we aren't htat toolchain21:43
yann|workas I read it, it is more for specifying a hardware vendor than a software one21:43
kergothcheck the autoconf docs, it probably originated there, given thats where the --build/--host/--target notions come from21:44
* kergoth shrugs21:44
kergothsee e.g. build_vendor21:44
yann|workkergoth: in their case it's not even the toolchain, they hacked config.guess to return what they want21:44
kergothwell, naturally that won't be of much use to us, the whole notion of config.guess is to return a string about the build environment, not target, which breaks assumptions in the cross-compilation case21:45
kergothregarding conditionals using the system type string, from the autoconf docs: Whenever you're tempted to use ‘$host’ it's worth considering whether some sort of probe would be better. New system types come along periodically or previously missing features are added. Well-written probes can adapt themselves to such things, but hard-coded lists of names can't.21:46
kergothsee 14.3 Using the System Type21:46
kergothsounds like they're violating that recommendation, and its' biting us now, as you'd expect it to21:47
fray(you have to remember autoconf probes for such things as the length of a char.. and uint_8  :)21:47
kergothtrue, but they're right about this, use info about what you need, not a hardcoded string from the system type21:47
*** vmeson <vmeson!~rmacleod@> has quit IRC21:49
*** dreyna4529 <dreyna4529!> has joined #yocto21:51
*** pohly <pohly!> has joined #yocto21:52
*** tsramos <tsramos!~tsramos@> has quit IRC21:52
yann|workkergoth: the rpi is apparently often used for on-target compilation21:53
*** IvanSB_ <IvanSB_!~IvanSB@2a01:2000:2000:2fd5:f279:59ff:fe64:3a8> has joined #yocto21:54
yann|workthx, you helped make my bugreport better ;)21:54
*** blueness_ <blueness_!> has joined #yocto21:55
*** Guest41021 <Guest41021!~vivek@> has joined #yocto21:58
*** manuel_ <manuel_!~manuel@> has quit IRC22:00
*** IvanSB_ <IvanSB_!~IvanSB@2a01:2000:2000:2fd5:f279:59ff:fe64:3a8> has quit IRC22:01
*** pidge_ <pidge_!~pidge@> has joined #yocto22:07
*** aehs29 <aehs29!~aehernan@> has left #yocto22:09
denixis there a way to clean sysroot (and/or tmp/work) w/o cleaning images and packages in deploy?22:10
*** pohly <pohly!> has quit IRC22:13
alimon1denix: you can use cleanall (sstate, srcs) or cleansstate over the recipe this causes to build again22:19
denixalimon1: not what I'm looking for22:19
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto22:20
alimon1denix: you can do a simply rm -r :D22:20
*** manuel_ <manuel_!~manuel@> has joined #yocto22:21
khemdenix: angstrom host DEPLOY_DIR outside TMP_DIR thats something you can look at22:22
denixkhem: per recipe, not completely22:23
denixand the trick is not angstrom specific - we used to do that back in classic days...22:24
*** cbzx <cbzx!> has joined #yocto22:24
khem`bitbake -ccleanall <recipe>22:24
khem`doesnt that do that job ?22:24
denixkhem: it also removes corresponding packages and images22:25
khem`yes so what is your usecase ?22:25
khem`sometimes you need to step back and redefine your problem22:25
denixkhem: I just need to nuke sysroot for a specific recipe22:25
*** pumpernickel_ <pumpernickel_!> has joined #yocto22:25
khem`what is the end goal its achieving ?22:26
denixI'm just experimenting with something here, was just wondering if it was possible to preserve built artifacts for a recipe when cleaning it up22:28
kergothafaik -c clean doesn't remove images, so don't really see the issue there22:28
kergothkhem`: -c cleanall != -c fetchall. cleanall still runs against one recipe, just also removes sources from DL_DIR22:28
kergothinconsistency in our naming (one of many)22:28
*** IvanSB_ <IvanSB_!> has joined #yocto22:29
kergothyou could create a task like fetchall which runs clean against the recipe and all its deps22:29
denixkergoth: I thought so too, but it seems to remove corresponding images in deploy and packages in ipks... :(22:29
kergothwould be just a few lines22:29
kergothpackages in ipks, of course22:29
kergothbut i thought DEPLOY_DIR_IMAGE was handled differently22:29
* kergoth shrugs22:29
kergothdenix: scripts/wipe-sysroot22:30
kergothlooks like it's probably just what you want22:30
*** stwcx <stwcx!~stwcx@> has quit IRC22:31
*** yann|work <yann|work!> has quit IRC22:31
*** sno <sno!> has joined #yocto22:31
pumpernickel_With a SRC_URI=file22:32
pumpernickel_Does bitbake know if that directory has been updated?22:32
denixkergoth: thanks! looking into it now22:32
pumpernickel_Or does the recipe revision need to be updated?22:32
kergothpumpernickel_: afaik it should be checksumming the input, recursively in the case of a directory, but i'm not certain22:32
kergoththat is, i know it handles files right, not sure about dirs offhand22:33
pumpernickel_I could double-check, I was curious if there was any expectation of that though.22:33
denixkergoth: seems to be all of sysroot though...22:33
pumpernickel_I've learned that I really won't understand bitbake without reading a bit of python.22:33
pumpernickel_We're trying to do too many non-standard things with it.22:34
rburtondenix: wipe-sysroot in scripts will clean the sysroot and all relevant stamps22:35
pumpernickel_kergoth: thanks22:36
denixrburton: I'm looking for cleaning a single recipe's sysroot. in other words, I want "bitbake recipe -c clean" to preserve packages and images - any quick ideas?22:36
*** adtec_ <adtec_!> has quit IRC22:36
rburton(presumably you meant the work directory, recipes don't have their own sysroot)22:37
denixrburton: as in bbclass? it removes tmp/work, not sysroot22:38
denixrburton: well, packages, not recipes :) but still22:38
rburtonnot entirely sure i understand what you want to achieve then22:38
*** benjamirc <benjamirc!~besquive@> has quit IRC22:39
*** rburton <rburton!> has quit IRC22:40
denixrburton: let's say I have 2 mutually exclusive packages that provide the same virtual/blah, I need to build them both (switching PREFERRED_PROVIDER and bitbake -cclean in between) and keep their ipk packages and images in deploy for binary feeds and such22:41
*** ndec <ndec!~ndec@linaro/ndec> has quit IRC22:41
*** IvanSB_ <IvanSB_!> has quit IRC22:43
denixso, I'm fine cleaning corresponding sysroot, sstage, stamps, packagedata in between, as long as built artifacts are preserved...22:43
denixpossible or am I crazy?22:44
khem`kergoth: I understand that, the kind of clean denix might be needing could be done with -cclean or -ccleansstate iself22:45
denixkhem: correct22:45
*** pidge_ <pidge_!~pidge@> has quit IRC22:47
*** ndec <ndec!> has joined #yocto22:48
*** ndec <ndec!~ndec@linaro/ndec> has joined #yocto22:48
*** vmeson <vmeson!> has joined #yocto22:53
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC22:54
kergothpersonally i'd just copy out the artifacts i need at the end of the build, wipe tmp between builds, and call it a day22:56
* kergoth shrugs22:56
*** bfederau <bfederau!> has quit IRC23:01
*** fmeerkoetter <fmeerkoetter!> has quit IRC23:01
*** fmeerkoetter <fmeerkoetter!> has joined #yocto23:01
*** bfederau <bfederau!> has joined #yocto23:01
*** nighty^_ <nighty^_!> has quit IRC23:03
*** nighty^ <nighty^!> has joined #yocto23:03
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto23:04
khem`denix: I think what you are needing is another kind of clean-withoout-deploydir23:06
khem`not sure if thats a good idea23:06
denixkhem: looks like it23:06
khem`and whats the issue with ipk regneration ?23:07
khem`it will be overwritten on rebuild anyway23:07
denixkhem: why?23:08
khem`if the content is same23:10
khem`otherwise they are added23:11
*** IvanSB_ <IvanSB_!~IvanSB@2a01:2000:2000:2fd5:f279:59ff:fe64:3a8> has joined #yocto23:12
*** adelcast <adelcast!~adelcast@> has quit IRC23:13
*** scot <scot!~scot@> has quit IRC23:14
*** harisokanovic <harisokanovic!~harisokan@> has quit IRC23:14
*** rtollert <rtollert!~rtollert@> has quit IRC23:14
denixkhem: well, the content is mostly different - package1.ipk has file1.ext and package2.ipk has file2.ext, but both packages PROVIDE a common feature, selected with PREFERRED_PROVIDER23:15
*** manuel_ <manuel_!~manuel@> has quit IRC23:15
*** pumpernickel_ <pumpernickel_!> has quit IRC23:16
khem`denix: is this separable at DISTRO level ?23:17
khem`I wonder if the issue is more fundamental usage23:17
denixwhat do you mean at DISTRO level?23:18
*** IvanSB_ <IvanSB_!~IvanSB@2a01:2000:2000:2fd5:f279:59ff:fe64:3a8> has quit IRC23:20
*** manuel_ <manuel_!~manuel@> has joined #yocto23:22
*** scot <scot!~scot@> has joined #yocto23:22
*** IvanSB_ <IvanSB_!~IvanSB@2a01:2000:2000:2fd5:f279:59ff:fe64:3a8> has joined #yocto23:22
*** harisokanovic <harisokanovic!~harisokan@> has joined #yocto23:23
*** adelcast <adelcast!~adelcast@> has joined #yocto23:24
*** sjolley <sjolley!~sjolley@> has quit IRC23:24
*** rtollert <rtollert!~rtollert@> has joined #yocto23:25
*** ant_home <ant_home!~ant__@> has quit IRC23:26
*** manuel_ <manuel_!~manuel@> has quit IRC23:26
*** manuel_ <manuel_!~manuel@> has joined #yocto23:28
*** IvanSB_ <IvanSB_!~IvanSB@2a01:2000:2000:2fd5:f279:59ff:fe64:3a8> has quit IRC23:29
*** var_x <var_x!> has quit IRC23:30
*** sameo <sameo!samuel@nat/intel/x-taghbvhdjhalduqt> has joined #yocto23:31
* akuster evil laugh to self 23:36
*** akuster is now known as armpit23:37
*** manuel_ <manuel_!~manuel@> has quit IRC23:39
*** pidge_ <pidge_!~pidge@> has joined #yocto23:40
*** IvanSB_ <IvanSB_!~IvanSB@2a01:2000:2000:2fd5:f279:59ff:fe64:3a8> has joined #yocto23:41
*** manuel_ <manuel_!~manuel@> has joined #yocto23:42
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC23:43
*** manuel_ <manuel_!~manuel@> has quit IRC23:47
*** sjolley <sjolley!sjolley@nat/intel/x-xtahnaoinitrsgbv> has joined #yocto23:48
*** IvanSB_ <IvanSB_!~IvanSB@2a01:2000:2000:2fd5:f279:59ff:fe64:3a8> has quit IRC23:49
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto23:51
* armpit wonders if e-pint is IoT ?23:51
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:56
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto23:56
*** sjolley <sjolley!sjolley@nat/intel/x-xtahnaoinitrsgbv> has quit IRC23:57

Generated by 2.11.0 by Marius Gedminas - find it at!