Monday, 2013-07-22

*** B4gd3r <B4gd3r!~daniel@178.174.211.166> has quit IRC00:00
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC00:12
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto00:18
*** _julian_ <_julian_!~quassel@x2f122e2.dyn.telefonica.de> has joined #yocto00:19
*** _julian <_julian!~quassel@x2f1601a.dyn.telefonica.de> has quit IRC00:22
*** nitink <nitink!nitink@nat/intel/x-ttnidlhqsrtwtzps> has joined #yocto00:30
*** ralluri <ralluri!~ralluri@106.197.7.206> has joined #yocto01:00
-YoctoAutoBuilder- build #220 of nightly-mips is complete: Failure [failed Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-mips/builds/22001:07
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto01:07
-YoctoAutoBuilder- build #182 of nightly is complete: Failure [failed Building Images_10] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/18201:45
*** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has quit IRC02:41
*** varjaaks <varjaaks!~ralluri@223.229.181.84> has joined #yocto02:55
*** ralluri <ralluri!~ralluri@106.197.7.206> has quit IRC02:56
*** silviof1 <silviof1!~silviof@ppp-188-174-104-55.dynamic.mnet-online.de> has joined #yocto02:56
*** silviof <silviof!~silviof@ppp-188-174-121-135.dynamic.mnet-online.de> has quit IRC02:59
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC03:38
*** nitink <nitink!nitink@nat/intel/x-ttnidlhqsrtwtzps> has quit IRC04:04
*** doerrpau1 <doerrpau1!~doerrpau@cpe-70-124-65-123.austin.res.rr.com> has joined #yocto04:05
*** swex_ <swex_!~swex@217.197.255.96> has joined #yocto04:06
*** b1gtuna_ <b1gtuna_!~adam@206.116.3.18> has joined #yocto04:06
*** silviof2 <silviof2!~silviof@ppp-188-174-104-55.dynamic.mnet-online.de> has joined #yocto04:08
*** trollixx_ <trollixx_!~trollixx@sf.wisetroll.net> has joined #yocto04:09
*** lyang01 <lyang01!~lyang001@1.202.252.122> has joined #yocto04:10
*** swex <swex!~swex@217.197.255.96> has quit IRC04:13
*** trollixx <trollixx!~trollixx@sf.wisetroll.net> has quit IRC04:13
*** ralluri <ralluri!7370e76f@gateway/web/freenode/ip.115.112.231.111> has joined #yocto04:13
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto04:13
*** varjaaks <varjaaks!~ralluri@223.229.181.84> has quit IRC04:15
*** silviof1 <silviof1!~silviof@ppp-188-174-104-55.dynamic.mnet-online.de> has quit IRC04:18
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC04:18
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC04:18
*** doerrpau <doerrpau!~doerrpau@cpe-70-124-65-123.austin.res.rr.com> has quit IRC04:18
*** b1gtuna <b1gtuna!~adam@s206-116-3-18.bc.hsia.telus.net> has quit IRC04:18
*** lyang0 <lyang0!~lyang001@1.202.252.122> has quit IRC04:18
*** tsjsieb_1fk <tsjsieb_1fk!~tsjsieb@siebj.xs4all.nl> has quit IRC04:18
*** ralluri <ralluri!7370e76f@gateway/web/freenode/ip.115.112.231.111> has quit IRC04:24
*** ralluri <ralluri!7370e76f@gateway/web/freenode/ip.115.112.231.111> has joined #yocto04:25
*** mihai <mihai!~mihai@188.27.93.142> has quit IRC04:26
*** ralluri <ralluri!~ralluri@223.229.181.84> has joined #yocto04:26
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto04:28
*** ralluri <ralluri!~ralluri@223.229.181.84> has quit IRC04:30
*** ralluri <ralluri!~ralluri@223.229.181.84> has joined #yocto04:31
*** ralluri <ralluri!~ralluri@223.229.181.84> has quit IRC04:36
*** doerrpau1 <doerrpau1!~doerrpau@cpe-70-124-65-123.austin.res.rr.com> has quit IRC04:41
*** ralluri <ralluri!~ralluri@223.229.181.84> has joined #yocto04:41
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto05:12
*** zeeblex <zeeblex!apalalax@nat/intel/x-uyrieusctwiamzlq> has joined #yocto05:20
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC05:21
*** agust <agust!~agust@pD9E2F88F.dip0.t-ipconnect.de> has joined #yocto05:41
*** mihai <mihai!~mihai@192.198.151.44> has joined #yocto05:54
*** ralluri <ralluri!~ralluri@223.229.181.84> has quit IRC06:10
*** ka6sox is now known as ka6sox-away06:11
*** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto06:31
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC06:35
*** ralluri <ralluri!~ralluri@223.227.203.149> has joined #yocto06:36
*** cristianiorga <cristianiorga!~cristiani@134.134.137.75> has joined #yocto06:39
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto06:40
*** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has joined #yocto06:41
*** Saur1 <Saur1!pkj@nat/axis/x-xeffojlhkjontlrw> has joined #yocto06:44
*** Saur <Saur!pkj@nat/axis/x-ctrtegclbovaourm> has quit IRC06:45
*** francois99 <francois99!~francois9@78-33-60-6.static.enta.net> has joined #yocto06:45
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto06:48
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto06:56
*** ralluri <ralluri!~ralluri@223.227.203.149> has quit IRC07:11
*** ralluri <ralluri!~ralluri@223.228.218.119> has joined #yocto07:20
*** slaine <slaine!~slaine@84.203.137.218> has joined #yocto07:21
*** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto07:22
*** ralluri <ralluri!~ralluri@223.228.218.119> has quit IRC07:25
*** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC07:25
*** varjaaks <varjaaks!~ralluri@106.198.38.125> has joined #yocto07:26
*** ralluri <ralluri!~ralluri@106.198.38.125> has joined #yocto07:26
*** slaine <slaine!~slaine@84.203.137.218> has quit IRC07:26
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto07:27
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has quit IRC07:27
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto07:27
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC07:27
*** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC07:28
*** varjaaks <varjaaks!~ralluri@223.238.130.32> has joined #yocto07:28
*** ralluri <ralluri!~ralluri@106.198.38.125> has quit IRC07:29
ant_workzecke: ping07:34
*** lpapp <lpapp!~lpapp@212.44.19.228> has joined #yocto07:36
zeckeant_work: hi07:40
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto07:40
ant_workhi07:41
ant_worktests ok. I'll send you an email now07:41
zeckeant_work: about which part? /proc/timer_list is kind of confirmed broken. the rest were some funnyness with porting. My 3.10.1 kernel boots.. my GSM BTS works.. and SD/MMC works when enabling the dma engine (not enabled by default and PIO mode of davinci_mmc is broken)07:42
ant_workI've booted and run your binary07:42
ant_workno issues (apart boot from mmc...)07:43
ant_workI've sent you the ipk07:43
zeckeant_work: thanks. https://lkml.org/lkml/2013/7/19/70607:44
*** varjaaks <varjaaks!~ralluri@223.238.130.32> has quit IRC07:48
*** ralluri <ralluri!~ralluri@223.238.130.32> has joined #yocto07:48
*** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto07:48
*** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto07:48
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto07:50
*** jonatan <jonatan!~quassel@194-237-7-146.customer.telia.com> has joined #yocto07:54
*** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC07:55
*** slaine <slaine!~slaine@84.203.137.218> has joined #yocto07:55
*** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC07:56
*** ralluri <ralluri!~ralluri@223.238.130.32> has quit IRC07:57
*** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto08:01
*** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto08:01
*** bluelightning <bluelightning!~paul@83.217.123.106> has joined #yocto08:06
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:06
lpappdo you plan to have recipes-kde?08:07
*** sameo <sameo!samuel@nat/intel/x-drnvkwvfjowdxbcr> has joined #yocto08:10
*** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has joined #yocto08:20
*** ralluri <ralluri!~ralluri@106.198.56.96> has joined #yocto08:23
bluelightningmorning all08:23
panda84kdemorning08:23
bluelightninglpapp: http://layers.openembedded.org/layerindex/layer/meta-kde/08:23
*** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC08:25
lpappbluelightning: thanks08:26
*** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC08:26
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has left #yocto08:26
lpappbluelightning: what is this sato layer? I read the recipes.txt, but I still do not get a clue.08:26
*** honschu_ <honschu_!~honschu@p549EBCDA.dip0.t-ipconnect.de> has joined #yocto08:27
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has joined #yocto08:27
*** belen <belen!Adium@nat/intel/x-joougdfprvnoxqsn> has joined #yocto08:27
bluelightninglpapp: Sato is the GUI environment we use for testing basic X11 functionality08:28
bluelightninglpapp: it's not a layer, it's part of OE-Core08:28
lpappbluelightning: yeah, it is recipes.08:28
*** b1gtuna_ <b1gtuna_!~adam@206.116.3.18> has quit IRC08:28
lpappbluelightning: honestly, I have never heard about it and I have been using Linux for 10+ years.08:29
lpappbluelightning: is it some custom application by yocto/oe/poky?08:29
*** b1gtuna <b1gtuna!~adam@s206-116-3-18.bc.hsia.telus.net> has joined #yocto08:29
panda84kdelpapp: http://www.pokylinux.org/about/08:29
panda84kdeit's a uber basic DE based on Matchbox WM08:30
bluelightninglpapp: kind of, it's been around since 2007 at least08:30
*** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC08:30
bluelightninglpapp: the point is it's simple and provides a stable testbed for X1108:30
panda84kdeplus an horrifying default green theme :)08:31
*** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto08:31
*** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto08:31
ant_workand doesn't fit on qvga08:32
lpappI really wonder why I have never heard this name before if it is such a good stuff.08:33
lpappprobably very domain specific.08:34
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC08:35
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto08:37
*** varjaaks <varjaaks!~ralluri@106.198.56.96> has joined #yocto08:42
*** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.85.234.195.229> has joined #yocto08:43
*** varjaaks <varjaaks!~ralluri@106.198.56.96> has quit IRC08:43
*** ralluri <ralluri!~ralluri@106.198.56.96> has quit IRC08:43
*** fabo <fabo!~fabo@linaro/fabo> has joined #yocto08:46
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto08:47
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has left #yocto08:48
*** ralluri <ralluri!~ralluri@223.228.122.184> has joined #yocto08:50
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto08:50
*** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC08:56
*** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto08:57
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto08:59
erenmorning all09:05
fenrigeren: morning ;)09:07
*** eren <eren!~eren@unaffiliated/eren> has quit IRC09:08
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto09:09
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto09:12
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC09:13
*** lpapp <lpapp!~lpapp@212.44.19.228> has quit IRC09:16
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto09:16
lpappcan I specify the layers before the build?09:18
lpappI mean without creating a build folder.09:19
lpappI would like to set them more persistently.09:19
*** smartin__ <smartin__!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto09:20
*** g0hl1n <g0hl1n!5be602f4@gateway/web/freenode/ip.91.230.2.244> has joined #yocto09:22
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC09:23
bluelightninglpapp: if the TEMPLATECONF variable is set in your environment prior to sourcing the oe-init-build-env script then it will pick up the template configuration files from there instead of meta-yocto/conf/09:25
*** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has quit IRC09:25
*** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has joined #yocto09:25
*** vmeson <vmeson!~quassel@128.224.252.2> has quit IRC09:25
*** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has joined #yocto09:26
*** vmeson <vmeson!~quassel@128.224.252.2> has joined #yocto09:27
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto09:28
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC09:30
*** lyang01 <lyang01!~lyang001@1.202.252.122> has quit IRC09:30
g0hl1nHello everyone09:34
g0hl1nI've a problem installing iptables...09:34
g0hl1nWhen I add iptables to the image I get following error when I want to execute it: FATAL: Module ip_tables not found. iptables v1.4.17: can't initialize iptables table `filter': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded.09:35
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto09:35
g0hl1nDoes anybody of you know what is needed to have the ip_tables module available in the image?09:35
*** lyang0 <lyang0!~lyang001@1.202.252.122> has joined #yocto09:36
bluelightningg0hl1n: sounds like your kernel configuration does not enable iptables/netfilter09:36
*** ralluri <ralluri!~ralluri@223.228.122.184> has quit IRC09:37
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has joined #yocto09:37
g0hl1nbluelightning: I've set CONFIG_IP_NF_IPTABLES=y in my kernel config. Shouldn't that be enough?09:38
bluelightningg0hl1n: what about CONFIG_IP_NF_FILTER ?09:45
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto09:50
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC10:01
*** ralluri <ralluri!~ralluri@223.228.122.184> has joined #yocto10:06
*** diego <diego!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto10:14
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC10:14
*** diego is now known as Guest9851910:14
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto10:15
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto10:32
lpappis there any documentation about "addtask" somewhere?10:32
g0hl1nbluelightning: ok, that wasn't set in my config. I'll try it.10:33
*** ralluri <ralluri!~ralluri@223.228.122.184> has quit IRC10:34
*** amarsman <amarsman!~marsman@84.241.214.153> has joined #yocto10:36
*** roric <roric!~roric@194-237-7-146.customer.telia.com> has joined #yocto10:36
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC10:38
*** amarsman <amarsman!~marsman@84.241.214.153> has quit IRC10:43
lpappis it an alright practice to create my own layer for our project, but only with the recipes folders we really need?10:45
lpappfor instance if we need a more up-to-date u-boot, only recipes-bsp?10:45
lpappor it is better to replicate every recipes folders?10:45
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto10:47
*** arky <arky!~arky@113.22.64.132> has joined #yocto10:48
ndeclpapp: you just need to create the folders you need. no need to add 'empty' folders.10:48
arkyIs there a tutorial for webkiosk buildling ? Thanks10:49
lpappndec: shall I copy the recipes.txt over, though?10:50
ndecno.10:50
ndecthat file is in meta/ for reference.10:50
lpappyeah, I have just checked other layers not copying it .10:50
lpappthough conf needs to be moved to a certain extent.10:51
ndecin fact nothing really even forces you to follow recipes.txt in your own layer.10:51
ndecyou have to comply to it, if you intend to upstream some recipes in oe-core or meta-oe, though.10:51
ndecconf?10:51
*** Guest98519 is now known as panda84kde10:52
lpappndec: the folder.10:52
ndecyou must have conf/layer.conf. that's what 'defines' a layer.10:53
ndecbeyond that, you are free to have whatever you need.10:53
lpappand I guess I need to disable the u-boot build from meta/recipes-bsp?10:54
ndecno.10:54
ndeceither your recipe 'overrides' the original one, with for example a different version.10:54
lpappah, ok. I guess it is based on priority?10:55
ndecor you can use a different recipe name, and tell OE to use that one instead.10:55
lpappbut then, how can one get both built?10:55
lpappequal priority?10:55
ndecdo you want both built?10:55
lpappI can imagine scenarios where it would be needed, yes.10:56
lpappnot in my particular case, but in other scenarios.10:56
ndecu-boot is 'just' a recipe that you add to your image. you might be able to add 2 uboot recipes in 1 image. but they need to be different recipe (e.g. different name).10:56
ndecnot different version of the same recipe10:57
lpappk10:57
*** flynn378 <flynn378!~AndChat27@75.76.29.10> has quit IRC10:58
*** mihai <mihai!~mihai@192.198.151.44> has quit IRC10:58
ndecwell, in fact you can set PREFERRED_PROVIDER_u-boot in your machine .conf file to indicate which u-boot recipe you need for a specific machine.10:58
lpappndec: what about meta-foo/conf/bar-local.conf?10:59
ndecwhat do you mena?10:59
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto10:59
ndecmean?10:59
*** mihai <mihai!~mihai@192.198.151.43> has joined #yocto11:00
lpappmeta-foo: own layer11:00
lpappbar-local.conf: config file for that own layer11:00
lpappwe have such a conf file now in meta-yocto/conf/11:00
lpappthis is probably a bad practice, and I need to move it onto meta-foo11:00
lpappwell, it might not be a bad practice11:00
lpappbut I guess I need the same conf in both layers?11:00
*** ralluri <ralluri!~ralluri@27.61.40.159> has joined #yocto11:01
ndeci am not sure i understand what information you put in this conf file.11:01
bluelightninglpapp: the idea is you should have your customisations in a distro config - conf/distro/distroname.conf11:01
*** varjaaks <varjaaks!~ralluri@27.61.40.159> has joined #yocto11:01
bluelightninglpapp: then you set DISTRO = "distroname" in local.conf and you've then enabled that set of configuration11:02
*** swex__ <swex__!~swex@178.132.101.134> has joined #yocto11:02
bluelightninglpapp: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-your-own-distribution11:02
lpappbluelightning: distro is poky.11:03
lpappwith only slight mods.11:03
lpapplike kernel adaptation for our board.11:03
lpappand custom u-boot.11:03
*** swex_ <swex_!~swex@217.197.255.96> has quit IRC11:05
lpappalthough, yeah... we have our foo.conf and foo-tiny.conf11:06
lpappit is confusing to me though that poky-tiny includes poky, and not the other way around.11:06
lpappshouldn't the "more complete" extend the tiny?11:07
ndecit's the otherway around. poky tiny is a customized poky with minimal config.11:08
bluelightninglpapp: if you're changing anything you should really create your own distro config11:08
ndeclpapp: if you have foo.conf already, you have your distro already. it's better to include poky.conf in foo.conf, that anything else. i am not sure how you include foo.conf today.11:09
lpappbluelightning: so every minor change means a different distribution then?11:10
lpappincluding a one-liner patch?11:10
bluelightninglpapp: no, it's just that for embedded applications it's pretty rare for people to want only one change11:11
ndecit depends on the one-liner patch ;-)11:11
lpappbluelightning: then I am lost.11:11
lpappbluelightning: we only have some kernel hardware adaptation, but that is pretty much it.11:11
lpappand obviously, u-boot is also hardware specific, so we need to adapt that, too.11:12
lpappeverything else is the same as in poky.11:12
bluelightninglpapp: you have a foo.conf file you are including right now, is that correct? what does that have in it?11:12
lpappdepends on what you mean by foo.cong.11:12
lpappconf*11:12
ndecyou mentioned it11:13
ndec<lpapp> although, yeah... we have our foo.conf and foo-tiny.conf11:13
lpappI mentioned other foo.conf before, too.11:13
lpappin conf.11:13
bluelightningas far as best practices go, anything that is machine specific belongs in a separate layer for the machine, which would include your kernel config, u-boot etc. and there would be a conf/machine/machinename.conf which would select those things and specify anything else custom for the machine11:15
lpappPREFERRED_VERSION_ubev ?= "141" -> this must be a typo, can you confirm that11:15
lpappI guess it should have been "udev".11:15
lpappfrom the look of it.11:16
bluelightningyep looks like a typo11:16
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto11:16
lpappbluelightning: what about that best practice?11:16
lpappadaptation means a new distribution?11:16
bluelightningthen, if you want anything else configured that's not machine-specific and isn't going to be different based on whose machine it's building on (i.e. local paths) then that belongs in a distro config11:16
lpappfor exactly the same package versions with adaptation patches?11:16
bluelightningthat way, rather than throwing a bunch of boilerplate into local.conf, users just need to include your layers, set DISTRO = "distroname" and then they're ready to go11:17
*** ralluri <ralluri!~ralluri@27.61.40.159> has quit IRC11:17
*** varjaaks <varjaaks!~ralluri@27.61.40.159> has quit IRC11:17
bluelightninglpapp: adaptation to your machine, no11:17
bluelightninglpapp: any other customisations that are specific to your usage of the machine as opposed to the machine itself, yes11:17
bluelightningbbl11:17
*** arky <arky!~arky@113.22.64.132> has quit IRC11:18
*** ralluri <ralluri!~ralluri@223.228.31.5> has joined #yocto11:20
lpappbluelightning: right, so a different version of u-boot yields a different distribution, right?11:25
lpappbluelightning: the distribution files should not go into the meta-yocto layer, right?11:25
lpappbluelightning: we do not need this stuff either, right? PREFERRED_VERSION_linux-yocto*11:27
lpappbut perhaps PREFERRED_VERSION_linux-foo* instead, or not even that?11:27
*** arky <arky!~arky@113.22.26.168> has joined #yocto11:31
*** mihai <mihai!~mihai@192.198.151.43> has quit IRC11:31
lpappthis should also go into the own layer? ../meta/recipes-core/psplash/files/psplash-foo-img.h11:33
*** mihai <mihai!mihai@nat/intel/x-djmzjbioktuojuyy> has joined #yocto11:33
*** tbn <tbn!~tbn@mad27-1-88-172-46-29.fbx.proxad.net> has joined #yocto11:39
*** tbn is now known as Guest7696411:40
*** joeythesaint <joeythesaint!~jjm@128.224.252.2> has joined #yocto11:50
lpappBBFILE_PRIORITY_foo = "6" -> in order to take my u-boot version rather than the old one from meta/recipes-bsp, right?11:54
lpapp"The BBFILE_PATTERN variable is set to a regular expression and is used to match files from BBFILES into a particular layer. In this case, LAYERDIR is used to make BBFILE_PATTERN match within the layer's path." -> I am not sure that makes the intent clear for me.11:57
lpappi.e. it is not describing why a "match" has to happen.11:57
*** amarsman <amarsman!~marsman@84.241.214.153> has joined #yocto12:01
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto12:09
*** ralluri <ralluri!~ralluri@223.228.31.5> has quit IRC12:18
bluelightninglpapp: re u-boot, it is very common for BSP (machine) layers to introduce their own customised versions of u-boot, so that's not really distro-related12:19
bluelightninglpapp: you'd create your own distro layer and not put those files in meta-yocto, correct12:19
bluelightninglpapp: PREFERRED_VERSION is only useful if you want to make a selection between multiple available versions where those exist12:20
bluelightninglpapp: a match has to happen in order for bitbake to find any recipes or bbappend files12:20
bluelightninglpapp: it is only through BBFILES and BBFILE_PATTERN that that can occur12:21
*** amarsman <amarsman!~marsman@84.241.214.153> has quit IRC12:21
lpappbluelightning: but if I do not need distro-related stuff, just machine, I am lost.12:21
lpappit is more accurate to call it a "bsp layer" rather than "distro layer"?12:21
bluelightninglpapp: in that case feel free to not create a distro layer, no need to be lost :)12:21
bluelightninglpapp: BSP layer and distro layer are different things12:22
bluelightninglpapp: a BSP is for supporting your specific machine12:22
lpappbluelightning: yes, that is why I prefer the "bsp layer" term.12:22
bluelightninglpapp: a distro layer is for configuration/customisations that are not specific to the machine, rather the use the machine is put to12:22
*** volker <volker!~volker@host-80-81-19-29.customer.m-online.net> has joined #yocto12:23
lpappin which case, conf/distro is kinda moot.12:23
lpappwe are fine with poky on this machine.12:23
lpappwe only need the bsp adaptation.12:23
lpappat least for now, that is.12:23
bluelightningthen, feel free to stick to it :)12:23
lpappwell, I do not see much difference, really.12:23
lpappexcept the fact, I would not have conf/distro/foo.conf12:23
lpappbut to be honest, I do not mind having that either.12:24
lpappit is not the main question to me.12:24
bluelightningif you're not providing a custom distro config you don't need conf/distro in your custom layer12:25
lpappbluelightning: I still do not understand the point of BBFILE_PATTERN12:25
lpappwhat additional benefit does it bring compared to BBFILES?12:25
*** amarsman <amarsman!~marsman@84.241.214.153> has joined #yocto12:25
lpappbluelightning: it would be nice to have a custom tiny distribution, even smaller than poky-tiny, but I do not think we have the man power for maintaining one.12:25
lpappso we have got to stick to poky, I am afraid.12:26
bluelightninglpapp: that's totally fine12:26
*** amarsman <amarsman!~marsman@84.241.214.153> has quit IRC12:26
lpappso, how is yocto different to mer/sailfish os?12:26
lpappoe/yocto to mer/sailfish?12:26
bluelightninglpapp: BBFILE_PATTERN is so that bitbake can associate files that are picked up from BBFILES with a particular layer, since BBFILES is just a list of paths12:27
bluelightninglpapp: feel free to consider it boilerplate for your layer.conf12:27
bluelightninglpapp: I have very little experience with either of those12:27
lpappbluelightning: I think BBFILE_PATTERN is useless.12:28
lpappnot now, but the concept.12:28
lpappI mean, you seem to filter in two-layers instead of one.12:28
lpapp1) You specify a list12:28
lpapp2) Then you filter the list12:28
lpapphow about this instead:12:28
lpapp1) Use a proper filter list?12:28
bluelightninglpapp: how would that look exactly?12:29
lpappcustom splash would also go into the bsp layer?12:29
volkeris there a possibility to use bitbake searching in recipes for specific text strings? I ask because the directory layout in poky is some kind of weird. having the source repositories on the same level as the build directory makes searching using regular linux tools quite slow12:30
ndecvolker: 'git grep' is your friend.12:31
ant_worklpapp: only an almost empty .bbappend and the logo-image..h12:31
bluelightninglpapp: typically no; there's nothing to prevent you from doing that but we recommend such things go in the distro layer since they aren't actually specific to the machine12:31
volkerndec: but then I have to do git grep for every single repository if I checked out several layers from different vendors12:31
bluelightningvolker: indeed, "git grep" works well for me12:32
ant_worklpapp: but yes, better to keep it distro-specific12:32
volkerunder angstrom distribution the meta layer directories were placed under "source" so you could just limit the search to this directory12:32
lpappbluelightning: can I have the bsp and distro layer together?12:32
ndecvolker: i generally use 'repo' then to manage multiple trees. then 'repo grep' would become your friend ;-)12:32
lpappbluelightning: something like meta-ti?12:32
lpappor I should separate them?12:32
volkerndec: will check that, but having meta directories under a source directory as it was used by angstrom seems a much simpler and cleaner solution to me,... just my two cents12:33
ant_worklpapp: better to keep a logical separation. In fact only the recipes in the BSP layers are machine-specific12:34
*** lh <lh!lh@osuosl/staff/lh> has quit IRC12:34
ant_worklpapp: you hit a bad example...12:34
lpappant_work: why?12:35
bluelightninglpapp: best practice is to keep them separate; the idea is you can switch out your BSP layer without losing your customisations12:35
ant_workother distros/people could be interested and reuse your generic layer12:35
bluelightninglpapp: they can of course appear in the same repo if that helps12:35
lpappthose are tight together for the next 10 years12:35
lpappor so. :)12:35
lpappso imo, separating them might be complication only.12:36
lpappwhat about the meta/recipes-foo?12:37
ant_worklpapp: we use a modified linux-yocto-tiny kernel from oe-core passing through two more layers12:37
lpappshould that go into the meta-$distro?12:37
lpappso?12:37
lpappit is a different use case.12:37
lpappthey are not tied together in your scenario.12:37
lpappso there must be some flexibility.12:37
lpappit is not much so in my corporate case.12:38
ant_workit's just a bit more burden for maintanance, not so much12:38
ant_workyou have one layer as common software collection / distro and one BSP for each SOC/machine you'd need in future12:39
lpappas I said, it is not like that.12:39
lpappthere will be one hardware with one distro for the next one decade or so12:39
lpapptry to decouple your mind from general open source stuff... ;)12:40
ant_workthen flatten all down if you feel more comfortable with it12:40
bluelightninglpapp: imagine that in 5 years you are forced to pick a new platform due to hardware availability issues. you'll then appreciate forward planning for that possibility...12:45
bluelightninglpapp: even different revs of the same hardware might be quite different internally, requiring different kernel configs, etc.12:46
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC12:49
*** challinan <challinan!~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has joined #yocto12:50
lpappbluelightning: trust me. :)12:58
lpappI know the business deal more... ;)12:58
lpappbtw, it is interesting that these files were removed in later poky versions, http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/machine?h=denzil12:59
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-ijzkeiaqbbkoefwd> has joined #yocto12:59
*** bluelightning_ <bluelightning_!~paul@83.217.123.106> has joined #yocto12:59
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto12:59
lpappbtw, how can I view the splash screen out of a header file provided to Yocto?12:59
lpappis there some generator for it?12:59
JaMasgw1: there is small issue in one of my patches included in last consolidated pull request, can you drop it or should I fix it in follow-up patch? I have many more dependency-fixes in queue13:00
JaMa"gst-plugins-bad: add few more PACKAGECONFIGs"13:00
lpappbluelightning: btw, do I need a .bbappend for the splash screen, too?13:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:02
lpappBBLAYERS variable in your conf/bblayers.conf file, which is found in the Build Directory. -> I have to create this before running bitbake then?13:03
lpappis there a more elegant way?13:03
lpappI cannot believe it is the right way for each build. :)13:03
lpappis there a more "catch-all" place?13:03
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC13:04
lpappalso, it would mean we check build folders into the repository which is bad.13:05
lpapp"Also, the layer priority does not currently affect the precedence order of .conf or .bbclass files. Future versions of BitBake might address this." -> hmm.13:21
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto13:28
ndecbluelightning_: so , i have resurected the EGL/mesa patch story... so the original patch 'fix-egl-compilation-without-x11' really needs to be replaced by the new patch which i have backported. with the original patch mesa builds without X11, since the patch adds something like this:-DMESA_EGL_NO_X11_HEADERS. however anybody that builds against mesa also needs to add the same flags or we don't get the right defs in the .h files.13:29
ndecand this isn't quite nice, nor good.13:29
lpapphow can I clean up the build folder?13:29
lpappI cannot just rm -rf it, as I need to keep the bblayers config file around...13:29
ndecwith the new backported patch, the headers files are set properly, when X11 isnt' there.13:29
ndecbluelightning_: the culprit is EGL/eglplatform.h13:30
ndecso overall, i think the patch improves the situation. it's been merged in master already, and my backport would apply the same change in dylan.13:30
ndeci just realized that i didn't remove the .patch , so either you can do it, or i could resubmut.13:31
*** ErkiS <ErkiS!~erki@pro01.dcc.ttu.ee> has joined #yocto13:31
bluelightning_ndec: OK, that sounds reasonable; would you mind sending a new version of the patch making that clearer in the commit message?13:31
ndecok. and btw, the commit message was copy/paste from the commit in master ;-)13:31
ndeci haven't checked though if that patch has been updated in master in the last couple of weeks.13:32
bluelightning_ndec: right, fair enough :)13:32
ndeci will resent today.13:32
bluelightning_ndec: thanks13:32
lpapp../meta/recipes-core/psplash/files/psplash-foo-img.h should go to ../meta-foo/recipes-core/psplash/files/psplash-foo-img.h?13:33
lpappalso, should I use .bbapends for a newer u-boot version, or a brand new stuff?13:40
*** dv__ <dv__!~quassel@chello080108009040.14.11.vie.surfer.at> has joined #yocto13:41
*** dv_ <dv_!~quassel@chello080108009040.14.11.vie.surfer.at> has quit IRC13:41
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto13:45
*** tbn_ <tbn_!~tbn@84.55.160.118> has joined #yocto13:46
ndeclpapp: for uboot, it's better/easier to just create your own recipe, e.g. u-boot-lpapp that is specific for your machine.13:46
lpappndec: in which layer, and why?13:46
ndecin your BSP layer.13:46
lpappwhy not just u-boot with higher priority than oe-core?13:47
ndecwhy? unless you can reuse uboot from OE, as it is, and you only need minor tweak which can go into bbappend.13:47
ndecbut most of the time uboot really needs to be customized for the target h/w, sometimes with a vendor tree, ...13:47
ndecin which case it's easier to go with your own recipe.13:47
* lpapp does not follow13:47
ndecso first, .bbappends is not appropriate for newer version of recipe. .bbappends is to 'overlay' an existing pair of recipe/version.13:48
lpappyes13:49
lpappagree13:49
ndecand as i think a few of us told this morning, u-boot is kind of 'special' case, and most people tend to make their own recipe, as very few people end up using the upstream uboot in real life.13:49
lpappwe do.13:49
*** Guest76964 <Guest76964!~tbn@mad27-1-88-172-46-29.fbx.proxad.net> has quit IRC13:49
lpappwe have one custom patch.13:50
lpappI think that is what people should do.13:50
ndecso, if you have a minor patch/tweak *and* you use the uboot version that is in OE already, then, .bbappend is appropriate.13:51
lpappno, oe-core has an overly outdated version.13:51
ndecbut note that you don't control the version of uboot you use. if OE upgrades to new uboot, you have to do the same.13:51
lpappthat means what?13:52
ndecif you use a .bbappend in your layer, you reply on the .bb in OE, you agree?13:52
lpappyes, but that is not the main question in here.13:52
lpappI was wondering why I would need u-boot-lpapp instead of u-boot.13:52
ndecso if OE .bb file changes to newer version, you are impacted.13:52
ndecif you use a vendor tree for example.13:53
ndecif what you need is too much different from uboot from OE. then you make yours.13:53
lpappnot sure I follow.13:53
lpappthe priority is set to my layer.13:53
lpappso I would not be any affected.13:53
lpappand that does not require lpapp suffix.13:53
ndecif you use .bbappend, the priority doesn't matter.13:54
lpappwell, we would not like to differ much from upstream.13:54
lpappit would be nice to have the patch always updated to the latest upstream version.13:54
lpappyou seem to have stuck with .bbappend, apparently.13:54
lpapp"I was wondering why I would need u-boot-lpapp instead of u-boot.13:54
lpapp"13:54
lpapp.bbappend file is not related to that.13:55
*** arky <arky!~arky@113.22.26.168> has quit IRC13:55
ndeci think i have said why or when u-boot-<lpapp> would be more appropriate. if you do that, you end up with your own recipe. and you control its name and version.13:57
lpappI still do not understand why13:57
lpappit is u-boot after all.13:58
*** simon_b <simon_b!c06dbe58@gateway/web/freenode/ip.192.109.190.88> has joined #yocto13:58
simon_bHello13:58
lpappit is not a forked u-boot.13:58
simon_bI would like to add dlt-daemons systemd files into an image. Therer is an rpm created which contains the files, but how do I get them into an image?13:59
ndecthen, good for you. the flexibility is there to allow others people which are less lucky than you, who need to deal with u-boot fork, such as vendors fork.13:59
lpappndec: we have one custom patch on top of u-boot upstream.13:59
*** icanicant <icanicant!~klawson@195.88.236.129> has quit IRC13:59
lpappndec: similar to something when desktop distributions have custom distro specific patches.13:59
lpappbut they do not fork the packages.13:59
ndecyes, you said that a couple of times.13:59
lpappyes, a patch is not a fork.13:59
dzoeHi (again), I'm still in the process of removing avahi from the image I'm trying to build. Although zeroconf is absent from DISTRO_FEATURES, avahi-daemon gets built. Using depexp I found that there's only a circular dependency libnss-mdns <-> avahi and nothing else.14:00
lpappwe still update our changes based on upstream.14:00
lpappbtw, is there an option for automatically updating the sha1 and md5?14:00
dzoeShould I try editing packagegroup-base to confirm my suspiction that it gets pulled from somewhere else?14:00
dzoe(8.0.1 Dylan, that is ... no way to migrate to Danny though)14:00
ndeclpapp: well, desktop distro do make fork in reality.14:00
ndecbut that's not the point of our discussion..14:00
lpappno, they do not fork.14:01
simon_boh: there is already an RDEPENDS against dlt-daemon.systemd inside the /systemd/system/basic.target.wants/dlt-system.service , but still it is not put into the image14:01
*** ka6sox-away is now known as ka6sox14:01
simon_bdlt-daemon.systemd -> dlt-daemon-systemd14:01
lpappI think for makepkg (archlinux), we had an option for automatically updating the checksum in the pkgbuild file.14:04
lpappis there something like that for bitbake?14:04
simon_b systemd/system/basic.target.wants/dlt-system.service -> meta-ivi/recipes-yocto-ivi/pacakgegroups/pacakgegroup-specific-component-p1.bb (copy paster error)14:04
* lpapp needs to study how the custom patches to recipes work14:07
*** arky <arky!~arky@113.22.48.5> has joined #yocto14:07
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC14:09
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto14:09
*** icanicant <icanicant!~klawson@195.88.236.129> has joined #yocto14:11
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC14:14
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto14:14
*** simon_b <simon_b!c06dbe58@gateway/web/freenode/ip.192.109.190.88> has quit IRC14:17
ant_worklpapp: it even spits you the expected checksum. It's up to a human to decide if the tarball is corrupted or not14:20
*** roric <roric!~roric@194-237-7-146.customer.telia.com> has quit IRC14:21
*** jonatan <jonatan!~quassel@194-237-7-146.customer.telia.com> has quit IRC14:21
*** sveinse <sveinse!~chatzilla@79.160.140.131> has joined #yocto14:23
*** roric <roric!~roric@194-237-7-146.customer.telia.com> has joined #yocto14:25
*** jonatan <jonatan!~quassel@194-237-7-146.customer.telia.com> has joined #yocto14:25
sveinseI understand yocto has its own yocto kernel. Why and how is this different from the upstream kernel? I have my own HW and kernel (3.4.24) in which I'm trying to add a BSP for. Are there any yoctoisms I'd need in my kernel?14:26
* sveinse is yocto n00b14:26
*** zeeblex <zeeblex!apalalax@nat/intel/x-uyrieusctwiamzlq> has left #yocto14:26
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto14:29
*** belen <belen!Adium@nat/intel/x-joougdfprvnoxqsn> has quit IRC14:32
*** belen <belen!~Adium@134.134.139.72> has joined #yocto14:36
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC14:36
*** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has quit IRC14:37
*** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.85.234.195.229> has quit IRC14:40
*** belen <belen!~Adium@134.134.139.72> has quit IRC14:53
*** davest <davest!Adium@nat/intel/x-unkplzpvucqlzukm> has joined #yocto14:53
*** lh <lh!lh@gonzo.dicp.de> has joined #yocto14:57
*** lh <lh!lh@osuosl/staff/lh> has joined #yocto14:57
*** hollisb <hollisb!~hollisb@nat-wv.mentorg.com> has joined #yocto14:58
*** dv__ is now known as dv_15:00
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-ijzkeiaqbbkoefwd> has quit IRC15:01
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-wqnyoxhfxwqmqseq> has joined #yocto15:03
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-wqnyoxhfxwqmqseq> has quit IRC15:05
bluelightning_dzoe: not sure if you've already tried but the best means of analysing why it is in your image may be to look at the output of buildhistory15:09
*** rburton_ <rburton_!~rburton@35.106.2.81.in-addr.arpa> has quit IRC15:09
bluelightning_dzoe: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality15:10
bluelightning_dzoe: specifically the .dot graphs showing dependency information within the image15:10
dzoebluelightning_: I did and I found that DISTRO_FEATURES zeroconf pulled it in - however I didn't have zeroconf in DISTRO_FEATURES and after hacking packagegroup-base.bb and removing zeroconf stanzas, it disappeared.15:13
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto15:13
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto15:14
dzoebluelightning_: Seems to me like danny isn't honoring all DISTRO_FEATURES correctly - but maybe I'm overlooking something.15:14
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC15:14
dzoe(Forking packagegroup-base.bb and deleting unused recipes is fine for my work, but I'd like to understand what's going on...)15:14
*** ralluri <ralluri!~ralluri@223.238.95.176> has joined #yocto15:15
bluelightning_dzoe: so, the first thing is that there's a difference between what gets built and what gets included in the image15:15
*** belen <belen!~Adium@134.134.139.72> has joined #yocto15:15
bluelightning_dzoe: I think what's been happening in your case is that avahi is being built but not included15:15
bluelightning_dzoe: the way packagegroup-base is written, it unconditionally creates a packagegroup-base-zeroconf package and that has a runtime dependency on avahi-daemon15:16
bluelightning_dzoe: in order to be able to satisfy that, bitbake then must build avahi-daemon15:16
dzoebluelightning_: was included - I don't care about building it, that's okay, but it was in the image and was running after startup15:17
bluelightning_dzoe: OK, I wouldn't think it possible for that to be as a result of this recipe though15:18
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC15:20
*** belen <belen!~Adium@134.134.139.72> has quit IRC15:21
*** belen2 <belen2!Adium@nat/intel/x-vumytgetcbihabyx> has joined #yocto15:21
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto15:22
*** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC15:28
lpappbluelightning_: do you know if I can get the checksum updated automatically?15:29
*** arky <arky!~arky@113.22.48.5> has quit IRC15:30
bluelightning_lpapp: automatically at what time?15:31
lpappbluelightning_: by running a command15:32
*** ralluri <ralluri!~ralluri@223.238.95.176> has quit IRC15:32
lpappwith Archlinux, I place the files into the current folder, and I run makepkg -G15:32
lpappand the checksums are updated automatically.15:32
bluelightning_lpapp: I don't know of an existing script or command that will do that, however writing one would not be too difficult15:33
*** ralluri <ralluri!~ralluri@223.238.237.207> has joined #yocto15:35
*** ralluri <ralluri!~ralluri@223.238.237.207> has joined #yocto15:36
lpappbluelightning_: should be a bitbake option if you ask me.15:36
bluelightning_lpapp: bitbake doesn't ever modify its input files15:37
lpappbluelightning_: that should be changed, yes.15:37
bluelightning_no, it's a design decision; any such tool would need to be external15:37
lpappwhy ?15:37
lpappother tools have been doing that just fine.15:38
lpappand it is the most convenient way.15:38
bluelightning_lpapp: why would an external tool be a problem for this case?15:38
lpappit is such a common operation that external tools do not make sense IMHO.15:38
lpappit would be a problem because:15:38
lpappit is _external_.15:38
bluelightning_lpapp: but you're already running a separate command to do this, it's not part of the normal build...15:39
*** sameo <sameo!samuel@nat/intel/x-drnvkwvfjowdxbcr> has quit IRC15:39
lpappbluelightning_: so?15:39
lpappI do not think we need a separate tool for one tiny option.15:39
lpappI would not like to run a separate command.15:40
dzoebluelightning_: I'll try to trace the dependencies closer later, but right now I have virtually no clue why it is happening15:40
bluelightning_lpapp: it's not just one tiny option, it's a change in how bitbake behaves with regard to its input metadata15:40
bluelightning_dzoe: the buildhistory image info should help you do that - I'd be interested in the results15:40
lpappbluelightning_: I do not follow15:41
*** slaine <slaine!~slaine@84.203.137.218> has quit IRC15:41
lpappbluelightning_: updating something is not editing.15:41
lpappalthough it is still source compilation related.15:41
lpappit is a minor stuff.15:41
bluelightning_lpapp: bitbake does not modify its input metadata, what you're talking about is modification15:41
lpappyou could even tell bitbake update the md5sum before building15:41
lpappit really is bitbake scope.15:41
lpappbluelightning_: it is irrelevant what it does.15:41
lpappwhat matters in the end of the day, what is useful for end users.15:42
bluelightning_lpapp: sorry, but it is relevant15:42
lpapplet us agree to disagree15:42
bluelightning_lpapp: users should be able to have confidence that the system is not going to change the inputs that they give it particularly when it comes to checksums that should be protecting them from tampering in upstream sources15:43
lpappbluelightning_: why would users use an option which is totally irrelevant for their use case?15:43
lpappit would not be an obligation of course.15:44
lpappand would not be default either15:44
lpappso I fail to understand the concern.15:44
lpappis there a devtool already? If not, I think it is an overkill to create one.15:47
lpappif yes, it could be added in there, too.15:47
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has quit IRC15:47
*** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has joined #yocto15:51
*** tbn_ <tbn_!~tbn@84.55.160.118> has quit IRC15:58
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has quit IRC15:59
*** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has quit IRC16:00
lpapphttps://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide -> for me, it is not clear where to put patches.16:00
lpappis there a dedicated variable for those, or I need to use the do_patches function?16:00
lpappI am not sure I understand why http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot_2011.06.bb uses git and not a released version?16:01
*** ErkiS <ErkiS!~erki@pro01.dcc.ttu.ee> has quit IRC16:01
*** mihai <mihai!mihai@nat/intel/x-djmzjbioktuojuyy> has quit IRC16:06
erenlpapp: what do you mean, released version?16:08
lpapperen: that one is fetching the git repository.16:08
lpapperen: it is not taking the released tarball.16:08
eren# This revision corresponds to the tag "v2011.06"16:09
eren# We use the revision in order to avoid having to fetch it from the repo during parse16:09
erenI guess that explains it?16:09
erenit's not a big problem, I guess16:09
lpappnope16:09
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-gtfyocmcioldvwdy> has joined #yocto16:10
lpappI do not understand the second line at all.16:10
*** nitink <nitink!~nitink@134.134.137.71> has joined #yocto16:10
lpappwell, it is a big problem.16:10
lpappbecause people might follow this wrong way.16:10
*** sveinse <sveinse!~chatzilla@79.160.140.131> has quit IRC16:11
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC16:12
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-gtfyocmcioldvwdy> has quit IRC16:12
lpappI think it is more elegant to fetch the tarball.16:13
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto16:13
lpappwhich means the package should probably be rewritten unless I missed something.16:13
*** smartin__ <smartin__!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC16:14
lpappdoes that sound reasonable?16:14
erenwell, not at the moment :/16:15
erenprobably we should ask it to more experienced people16:16
lpapp?16:16
lpappit should not be difficult to write a package to change the download url16:16
bluelightning_lpapp: you may find looking through the git history for that recipe might explain what's going on there16:16
lpappbluelightning_: I do not have a clone16:16
bluelightning_lpapp: patches are referred to in SRC_URI16:17
bluelightning_lpapp: as with all other source files fetched for the recipe16:17
lpappbluelightning_: yeah, so not a dedicated file like with dpkg. :(16:18
bluelightning_lpapp: no, everything is in the recipe16:18
lpappbluelightning_: I cloned, but git log does not mention anything useful.16:19
lpappI do not think a release package is worth not using the release tarball.16:19
lpappto me, it seems a bad packaging QA.16:19
lpappand should be revamped.16:19
lpappshould be an oe-core change.16:20
lpappsince I need to write a package anyway, and I will not follow that stuff, I might just submit a patch against oe-core.16:20
zibrilpapp: what is the issue with fetching a tagged commit from git?16:20
zibriit *is* the release16:21
erenwhat's the difference between checking out the tag from which also the tarball is generated?16:21
lpappzibri: no, it is not.16:21
zibrioh no?16:21
lpappzibri: check the project's website where the released stuff is coming from.16:21
lpappI will help you:16:21
zibrii assume they don't tag random commits... but i don't know the u-boot release process ;)16:21
lpappftp://ftp.denx.de/pub/u-boot/16:22
*** pidge <pidge!pidge@nat/intel/x-nsvdonqtctqpdqzz> has joined #yocto16:22
lpappwell, the main desktop distributions do not work like this either.16:23
zibrii *think* the reason why the SRCREV is a sha1 and not a tag is that bitbake will fetch the tag to verify it hasn't changed.16:23
lpappalso, what if they migrate to svn16:23
lpappor anything else.16:23
lpappreally, it is a very bad decision packager made.16:23
zibrithen update the SRC_URI to svn instead of git? :)16:23
lpappor use a flexible and official way instead?16:23
lpappinstead of carrying the crap?16:23
zibri...16:23
lpapptell me, what the u-boot download link tells you?16:24
lpappgo to git and fetch?16:24
lpappor it gives the tarballs for downloading?16:24
erenit provides you options, I believe there is no "right" way for this stuff16:24
ereneither clone the tag, or download tarball for this tag16:24
lpappwhere do you see "git clone" for download ?16:25
lpappto get the release?16:25
lpappcould you please point me to the link?16:25
lpappthere *is* right way16:25
zibrilpapp: http://www.denx.de/wiki/U-Boot/SourceCode16:25
lpappwhich is the official way.16:25
zibrifirst bullet point: git :)16:25
lpappzibri: nice misinterpretation try.16:25
lpapp*** current *** source code16:26
zibrias well as history?16:26
lpappthey write with bold characters ....16:26
ndeclpapp: well, the official release email says that we can download from git, or ftp.16:26
lpappfor the fuck sake.16:26
zibriargh, i give up16:26
lpappthen the next bold line is: Released Versions (and some special snapshots) are available from the DENX FTP server16:26
erenzibri: I give up, as well16:26
ndecU-Boot v2011.06 has been released and is available from the git repository and the FTP server.16:26
ndechttp://lists.denx.de/pipermail/u-boot/2011-June/094956.html16:26
* lpapp is afraid of the oe/yocto packaging quality16:27
*** JimNH3 <JimNH3!~jmchale@23-25-235-113-static.hfc.comcastbusiness.net> has joined #yocto16:28
*** tomz <tomz!~trz@c-68-53-177-94.hsd1.in.comcast.net> has joined #yocto16:28
*** tomz is now known as Guest9117616:28
erenI believe we cannot judge packaging quality just by looking how it fetches source16:29
lpappoh yeah, sure, desktop distributions having a lot more packaging experience are all stupid16:29
ndeclpapp: debian packaging for u-boot: http://anonscm.debian.org/gitweb/?p=collab-maint/u-boot.git;a=commit;h=b1af6f532e0d348b153d5c148369229d24af361a16:30
lpappand perhaps Yocto is the right thing.16:30
ndecthey import the entire git history of the project.16:30
ndecit's even the very same commit SHA1 as in OE.16:30
kergothzibri: Use /ignore, I've felt better ever since :)16:30
ndeci think we can consider debian, as a decent desktop distro.16:30
erenndec: debian as a "decent" desktop distro?16:31
erenhm :)16:31
* ndec suddently hesitate who needs to be /ignored ;-)16:31
*** JimNH2 <JimNH2!~jmchale@23-25-235-113-static.hfc.comcastbusiness.net> has quit IRC16:31
erenhehehe :P16:31
erenwe need to define "decent" actually16:32
erenbut it would be off-topic here16:32
zibrikergoth: :)16:32
ndeci have the feeling there is a lot of off-topic today ;-)16:33
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:34
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC16:34
lpappndec: https://aur.archlinux.org/packages/ub/uboot-mkimage/PKGBUILD16:34
lpappyay, they are not dependent on the VCS?16:35
lpappthey use the official way from the website?16:35
ndeclpapp: and? that basically means that there is choice around. and it's good.16:35
lpappno16:35
lpappit means, they do not depend on the vcs, tag, server, whatever.16:36
lpappand they use the official way written on the website.16:36
erenbut the developers of u-boot depend on vcs, tag, server, whatever to actually produce that tarball? :)16:36
lpappand it also means they are not inconsistent unlike yocto and oe16:36
lpapplike few packages come from git, the other from tarball urls, etc.16:36
lpapperen: developers != packagers.16:37
lpappalso, pass mistakes are hardly excuse for introducing more.16:37
lpappI am sure the debian developers would appreciate contribution in this regard in line with their policies.16:38
lpappalso, if the history of the repository is modified, they also screws up the downstream packages, etc.16:39
lpappthat*16:40
lpappagain, I am surprised by the packaging quality.16:40
lpappthe only reason against ftp could be limited corporate environment where only http (8080) is allowed, and nothing else.16:41
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto16:41
lpappbut then, git will not work either anyway16:41
*** myopiate <myopiate!~myopiate@203.206.170.6> has quit IRC16:43
*** myopiate <myopiate!~myopiate@203-206-170-6.perm.iinet.net.au> has joined #yocto16:44
*** eren <eren!~eren@unaffiliated/eren> has quit IRC16:44
lpappfrom the debian mentor channel:16:45
lpapp17:41 < lpapp> hi, is it ok to package something from git for a stable release?16:45
lpapp17:41 < lpapp> or should we try to use the released tarball with the url coming from the website.16:45
lpapp17:42 < SamB> it's better if you can use a release, yes16:45
lpapp17:44 < SamB> and if upstream distributes release tarballs you should indeed use those rather than roll your own16:46
lpappndec: so, no, you cannot consider that debian package "decent".16:46
lpappis there any way to check out the splash header file? Some tool which converts it back to png?16:52
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto16:55
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC16:56
bluelightning_lpapp: not to my knowledge, unless there's something provided in the psplash code16:57
lpappbluelightning_: so how can one generate "image headers"?16:57
lpappit is pretty strange to have something like this.16:57
lpappis it Yocto specific?16:57
bluelightning_lpapp: it's psplash-specific16:57
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-jfktefpysnckwnqr> has joined #yocto16:58
bluelightning_lpapp: you can supply your own png in the SPLASH_IMAGES variable16:58
lpappno no, we use headers.16:58
bluelightning_it'll be converted automatically as part of the build16:58
lpapptry to open that up with an image viewer ...16:58
lpappsay, I have a png... how can I get a header file?16:58
bluelightning_lpapp: or, if you prefer, you can do the conversion once using the script supplied as part of the psplash source16:58
lpappwhat script?16:59
lpappbtw, psplash seems to be a yocto project, so it is relevant to Yocto.17:00
lpappkinda domain specific.17:00
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:00
bluelightning_lpapp: https://git.yoctoproject.org/cgit/cgit.cgi/psplash/tree/make-image-header.sh17:00
bluelightning_if you prefer you can always use your own splashscreen application17:01
bluelightning_or, none at all17:01
lpappbluelightning_: that script does not even have a help menu ...17:02
bluelightning_lpapp: it's not ideal I'll admit17:03
bluelightning_I'm sure patches would be welcome17:03
lpappbluelightning_: can you summarize how it must be used?17:03
lpappfrom the u-boot channel: 17:39 < lpapp> do you prefer us packagers to package the released tarball from ftp or git tag?17:04
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC17:04
lpapp18:02 < hofstee> lpapp: tarball seems more logical since you don't need the history, and tag and tarball should be equal17:04
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto17:04
lpappjust like I claimed several times above ...17:05
lpappI even offered the help with updating it... but it was not too much appreciated.17:05
lpappguess whether I help with it ...17:05
*** silviof2 <silviof2!~silviof@ppp-188-174-104-55.dynamic.mnet-online.de> has quit IRC17:05
lpappndec: also, they do *not* use git for debian17:06
lpappndec: that is just an additional metadata, but the source is not coming from there.17:06
bluelightning_lpapp: I guess I don't see why you're so hung up on this particular thing, it's not like the source will actually be different17:06
lpappSee? I would like to contribute, and then I am said "hung up"17:07
lpapp"better to ignore me" etc17:07
lpapp(this is not the first time for offering contribution for _free_)17:07
lpappto me, it seems awkward one needs to fight to be able to help.17:08
lpappeven over minor and trivial things.17:10
lpappI kinda expected, "sure, go ahead, that would be great!"17:10
lpappI will do it for myself, but I will not submit it to upstream as it would not be welcome anyway.17:11
bluelightning_lpapp: the thing is this is trivial; if the source code is the same it hardly matters where it is fetched from, the output will be the same17:11
lpappyou can say that against everyone else17:12
lpapparch, debian packagers, u-boot authors, etc.17:12
lpappif you do not care about what upstream suggests, probably it is not my cup of tea to contribute here.17:13
lpappwe have always respected upstream when doing packaging, no matter what.17:13
bluelightning_lpapp: correct me if I'm wrong but upstream didn't say "no you must use tarballs, set fire to anyone who is using git because that's just wrong and evil"17:13
lpappeveryone else said: tarball is preferred.17:14
lpappthere is technically hardly any reason to go against everyone else.17:14
lpappanyway, you all have managed to shut down my contribution motivation.17:14
bluelightning_I don't know the history here; maybe at one point it history it was found convenient to point to git in the event that we needed to incorporate one or two changes from git on top of a release17:14
lpappsurely, I am not willing to submit it upstream anymore17:14
lpappexcept that, it is pretty much the same.17:15
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC17:24
lpappbluelightning_: I asked several times for qt issues last time, but I did not get anything.17:25
lpappI feel it hard to contribute to the project, but I do not have much motivation anymore either to be honest. :)17:25
bluelightning_lpapp: I thought we had a reasonable discussion about that, maybe I wasn't around for everything17:26
lpappbluelightning_: no, I asked for reasons apart from the sdk why it is not mature17:26
lpappand I have not got any reasons really.17:26
lpappjust that "3 months is not enough to make it"17:26
lpappbluelightning_: what is the logic for putting patches into meta, meta-yocto, or an own layer?17:28
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC17:28
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto17:28
bluelightning_I have a meeting now unfortunately, bbl17:29
*** bluelightning1 <bluelightning1!~paul@83.217.123.106> has joined #yocto17:32
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC17:33
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:34
*** belen2 <belen2!Adium@nat/intel/x-vumytgetcbihabyx> has quit IRC17:40
lpappbluelightning1: should I put a local and site config into meta/meta-yocto/meta-foo or just meta-foo?17:41
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC17:52
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto17:53
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-jfktefpysnckwnqr> has quit IRC17:57
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-whupydfoovlyegra> has joined #yocto18:00
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto18:00
bluelightninglpapp: re your earlier question, none of us is currently close enough to work out what's missing if anything in meta-qt5 other than the obvious missing SDK support18:02
*** bluelightning1 <bluelightning1!~paul@83.217.123.106> has quit IRC18:02
bluelightninglpapp: which makes it hard for us to commit to pulling it into the core on some accelerated schedule when it is quite usable in its own layer for the time being18:02
bluelightninglpapp: with regard to where to put patches / configuration it depends on whether your change makes sense mostly just for your case or for all users18:04
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC18:07
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:26
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC18:29
*** joeythesaint <joeythesaint!~jjm@128.224.252.2> has quit IRC18:30
lpappoh, bluelightning has just left.18:37
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-whupydfoovlyegra> has quit IRC18:38
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-hfanxvxaigfyynlp> has joined #yocto18:41
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-hfanxvxaigfyynlp> has quit IRC18:46
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto18:46
*** varjaaks <varjaaks!~ralluri@223.228.59.211> has joined #yocto18:55
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC18:57
*** ralluri <ralluri!~ralluri@223.238.237.207> has quit IRC18:58
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-cozoqtitntgkeljb> has joined #yocto19:07
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-cozoqtitntgkeljb> has quit IRC19:08
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC19:15
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto19:18
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC19:19
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-fkllnjfsvjxgapae> has joined #yocto19:19
*** likewise <likewise!~chatzilla@ip503cba31.speed.planet.nl> has joined #yocto19:25
*** yzhao2_ <yzhao2_!~yzhao2@128.224.252.2> has joined #yocto19:29
*** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has quit IRC19:32
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC19:37
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto19:39
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto19:41
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto19:42
*** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC19:45
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC19:46
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC19:47
*** joeythesaint <joeythesaint!~jjm@206-248-190-39.dsl.teksavvy.com> has joined #yocto19:54
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-fkllnjfsvjxgapae> has quit IRC19:56
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-klbwlqcsweydnpth> has joined #yocto19:59
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has quit IRC20:10
sgw1Hi Khem: regarding bug #4854, do you think we need to investigate the tune file or qemu.  If the tune file any suggestions as to who can look into it?20:15
yoctiBug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4854 normal, Medium, ---, raj.khem, NEW , floor call (from math.h) is broken on qemuppc20:15
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC20:20
*** silviof2 <silviof2!~silviof@ppp-93-104-17-108.dynamic.mnet-online.de> has joined #yocto20:28
*** bluelightning <bluelightning!~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com> has joined #yocto20:29
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:29
lpappbluelightning: welcome back20:36
*** likewise <likewise!~chatzilla@ip503cba31.speed.planet.nl> has quit IRC20:37
bluelightninghi20:40
lpappbluelightning: what did you write last?20:40
* kergoth tries to whittle down the dependencies necessary to build systemd-tmpfiles20:40
*** trollixx_ <trollixx_!~trollixx@sf.wisetroll.net> has quit IRC20:41
*** trollixx <trollixx!~trollixx@sf.wisetroll.net> has joined #yocto20:41
bluelightninglpapp: http://logs.nslu2-linux.org/livelogs/yocto.txt20:42
lpapphmm, this channel is publically logged, and not mentioned in the topic?20:43
bluelightningI think it says "you may wish to"20:45
lpappthe freenode rule is to mention it if I recall correctly.20:46
lpappbluelightning: our patches are hardware adaptation mostly.20:48
lpappto linux, u-boot, etc.20:48
bluelightningso, it sounds like for the most part, they would be eminently suited for a BSP layer20:50
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-klbwlqcsweydnpth> has quit IRC20:51
b1gtunaGood afternoon everybody!20:51
b1gtunaIs there a replacement of busybox?20:51
b1gtunaSomething more.. fully featured?20:51
lpappbluelightning: is there a good example for applying packages in case of any package?20:52
kergothyes, the real applications.20:52
kergothwhich are many20:52
lpappb1gtuna: coreutils20:52
b1gtunahm20:52
b1gtunaya replacing busybox with individual packages will take some time20:52
b1gtunalpapp: coreutils?20:52
bluelightninglpapp: not sure I understand the question20:52
lpappb1gtuna: yes20:54
sgw1b1gtuna: the packagegroup-core-basic will go a long way to replacing busybox with the full featured commands, there is also a packagegroup-core-lsb which includes all the LSB (linux standard base)20:54
lpappbluelightning: ... for applying _patches_ ...20:54
kergothaha, thats the one, i knew there was a group but i couldnt' for the life of me remember what it was, thanks sgw1 :)20:54
* kergoth was thinking task-proper-tools, but that doesn't exist anymore20:54
bluelightninglpapp: sure, that's not the part I didn't understand though...20:54
*** sgw1 is now known as sgw_20:54
b1gtunalpapp sgw1 - sweet! configurable through DISTRO_FEATURES?20:55
sgw_kergoth: yeah, basic and lsb will help out.20:55
lpappbluelightning: I am looking for examples in the existing layers20:55
lpappbluelightning: how to do patching nicely.20:55
bluelightningb1gtuna: it's just a packagegroup you'd add to your existing image20:55
sgw_b1gtuna: more through your image creation and selection of what to install, see core-image-basic and core-image-lsb in meta/recipes-extended/images20:56
bluelightninglpapp: the BSP guide should be a good starting reference20:56
bluelightningbbl20:56
b1gtunabluelightning sgw_: makes sense. gracias!20:56
kergothgah, dumping the config.log files to the do_configure log is not cool20:57
kergothwe need a variable to toggle that behavior20:57
kergoththe end of the config.log is almost never of any use, its all the variables from the cache and crap20:57
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto20:57
kergothgaaaaah21:06
kergothi hate when i lose patches i had forgot to copy out of ${S}21:07
kergothdo a clean and time to do it over again21:07
kergothhmm, we really need to get the tmux terminal types fixed, i haven't had *any* time to look at it since it first got merged21:08
sgw_kergoth: been there done that too many times, we need a tool for that!21:13
kergothyes, indeed. push_my_patches_to_an_appropriate_path_in_filespath21:13
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-dqrwxkrtntxkqngm> has joined #yocto21:14
sgw_kergoth: historical question for you: it seems we keep 2 python sitecustomize.py files around, one for target and an identical one for -native/nativesdk-, it seems to me that it should are primary for the native and we should not be using the target it one, thoughts?21:16
kergothHonestly, I have no idea, I mostly punted and let mickey lauer handle python back in the day :)21:17
kergothit was unpleasant, as all the scripting language builds are21:17
sgw_kergoth: yeah, his name is in that file :-)!21:17
kergoth:)21:18
kergothokay, systemd-tmpfiles deps are down to intltool-native dbus libcap. I think this isn't unreasonable, think folks would object to that being pulled into non-systemd builds to transition away from populate-volatiles?21:26
*** ant_home <ant_home!~andrea@host133-7-dynamic.20-79-r.retail.telecomitalia.it> has joined #yocto21:27
kergothDoes anyone remember the bug where if you had multiple recipes using the same git repository, but differing SRCREVs based on the same branch, they'd fight over control of the autoincrementing number due to sharing the field in the persist_data db presumably, resulting in the recipe being rebuilt on every build, as the number would increment on every parse?21:33
kergothI'm thinking that may have been related to bug 3225 and tehrefore would have been resolved by the switch to the pr server21:33
yoctiBug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3225 normal, Medium, 1.4, constantinx.musca, RESOLVED FIXED, linux-yocto SRCPV is changed after every MACHINE switch21:33
kergothbut I'm uncertain, and we may need a workaround/fix for dylan21:33
JaMayes that's the issue21:35
JaManow PR server contains package architecture, so if it's MACHINE_ARCH recipe then it's fine21:36
JaMakey in PR server21:36
kergothokay, thats what i was thinking. think we'll just not use SRCPV for hte affected recipes, for now, for our old product which was prior to pr server21:36
*** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has joined #yocto21:43
*** darknighte_znc <darknighte_znc!~darknight@nat-lmt.mentorg.com> has joined #yocto21:54
*** darknighte_znc is now known as darknighte21:55
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto21:55
*** sameo <sameo!samuel@nat/intel/x-lwgoirshupqopfxx> has joined #yocto21:57
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto21:58
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC21:59
*** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has quit IRC22:11
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-dqrwxkrtntxkqngm> has quit IRC22:16
*** pidge <pidge!pidge@nat/intel/x-nsvdonqtctqpdqzz> has quit IRC22:19
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto22:20
*** zeddii <zeddii!~ddez@128.224.252.2> has quit IRC22:38
*** vmeson <vmeson!~quassel@128.224.252.2> has quit IRC22:38
*** vmeson <vmeson!~quassel@128.224.252.2> has joined #yocto22:40
*** yzhao2_ <yzhao2_!~yzhao2@128.224.252.2> has quit IRC22:40
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto22:42
*** zeddii <zeddii!~ddez@128.224.252.2> has joined #yocto22:42
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC22:45
*** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has joined #yocto22:47
*** agust <agust!~agust@pD9E2F88F.dip0.t-ipconnect.de> has quit IRC22:52
*** volker_ <volker_!~volker@host-80-81-19-29.customer.m-online.net> has joined #yocto22:54
*** volker_ is now known as Guest6808122:54
*** davest <davest!Adium@nat/intel/x-unkplzpvucqlzukm> has quit IRC22:58
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC23:00
*** volker <volker!~volker@host-80-81-19-29.customer.m-online.net> has quit IRC23:00
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC23:00
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC23:00
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto23:01
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto23:01
*** acidfu <acidfu!~nib@24.37.17.210> has joined #yocto23:01
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto23:01
*** ant_home <ant_home!~andrea@host133-7-dynamic.20-79-r.retail.telecomitalia.it> has quit IRC23:01
*** sameo <sameo!samuel@nat/intel/x-lwgoirshupqopfxx> has quit IRC23:14
*** ndec <ndec!~ndec@linaro/ndec> has quit IRC23:18
*** ndec <ndec!~ndec@2001:41d0:8:e632::1> has joined #yocto23:18
*** ndec <ndec!~ndec@linaro/ndec> has joined #yocto23:18
*** _julian_ <_julian_!~quassel@x2f122e2.dyn.telefonica.de> has quit IRC23:24
*** arky <arky!~arky@113.22.50.193> has joined #yocto23:26
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto23:44
*** arky <arky!~arky@113.22.50.193> has quit IRC23:45
*** _julian <_julian!~quassel@x2f04625.dyn.telefonica.de> has joined #yocto23:50
*** doerrpau <doerrpau!~doerrpau@cpe-70-124-65-123.austin.res.rr.com> has joined #yocto23:54
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC23:56

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!