*** B4gd3r <B4gd3r!~daniel@178.174.211.166> has quit IRC | 00:00 | |
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC | 00:12 | |
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto | 00:18 | |
*** _julian_ <_julian_!~quassel@x2f122e2.dyn.telefonica.de> has joined #yocto | 00:19 | |
*** _julian <_julian!~quassel@x2f1601a.dyn.telefonica.de> has quit IRC | 00:22 | |
*** nitink <nitink!nitink@nat/intel/x-ttnidlhqsrtwtzps> has joined #yocto | 00:30 | |
*** ralluri <ralluri!~ralluri@106.197.7.206> has joined #yocto | 01: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/220 | 01:07 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 01: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/182 | 01:45 | |
*** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has quit IRC | 02:41 | |
*** varjaaks <varjaaks!~ralluri@223.229.181.84> has joined #yocto | 02:55 | |
*** ralluri <ralluri!~ralluri@106.197.7.206> has quit IRC | 02:56 | |
*** silviof1 <silviof1!~silviof@ppp-188-174-104-55.dynamic.mnet-online.de> has joined #yocto | 02:56 | |
*** silviof <silviof!~silviof@ppp-188-174-121-135.dynamic.mnet-online.de> has quit IRC | 02:59 | |
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC | 03:38 | |
*** nitink <nitink!nitink@nat/intel/x-ttnidlhqsrtwtzps> has quit IRC | 04:04 | |
*** doerrpau1 <doerrpau1!~doerrpau@cpe-70-124-65-123.austin.res.rr.com> has joined #yocto | 04:05 | |
*** swex_ <swex_!~swex@217.197.255.96> has joined #yocto | 04:06 | |
*** b1gtuna_ <b1gtuna_!~adam@206.116.3.18> has joined #yocto | 04:06 | |
*** silviof2 <silviof2!~silviof@ppp-188-174-104-55.dynamic.mnet-online.de> has joined #yocto | 04:08 | |
*** trollixx_ <trollixx_!~trollixx@sf.wisetroll.net> has joined #yocto | 04:09 | |
*** lyang01 <lyang01!~lyang001@1.202.252.122> has joined #yocto | 04:10 | |
*** swex <swex!~swex@217.197.255.96> has quit IRC | 04:13 | |
*** trollixx <trollixx!~trollixx@sf.wisetroll.net> has quit IRC | 04:13 | |
*** ralluri <ralluri!7370e76f@gateway/web/freenode/ip.115.112.231.111> has joined #yocto | 04:13 | |
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 04:13 | |
*** varjaaks <varjaaks!~ralluri@223.229.181.84> has quit IRC | 04:15 | |
*** silviof1 <silviof1!~silviof@ppp-188-174-104-55.dynamic.mnet-online.de> has quit IRC | 04:18 | |
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 04:18 | |
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC | 04:18 | |
*** doerrpau <doerrpau!~doerrpau@cpe-70-124-65-123.austin.res.rr.com> has quit IRC | 04:18 | |
*** b1gtuna <b1gtuna!~adam@s206-116-3-18.bc.hsia.telus.net> has quit IRC | 04:18 | |
*** lyang0 <lyang0!~lyang001@1.202.252.122> has quit IRC | 04:18 | |
*** tsjsieb_1fk <tsjsieb_1fk!~tsjsieb@siebj.xs4all.nl> has quit IRC | 04:18 | |
*** ralluri <ralluri!7370e76f@gateway/web/freenode/ip.115.112.231.111> has quit IRC | 04:24 | |
*** ralluri <ralluri!7370e76f@gateway/web/freenode/ip.115.112.231.111> has joined #yocto | 04:25 | |
*** mihai <mihai!~mihai@188.27.93.142> has quit IRC | 04:26 | |
*** ralluri <ralluri!~ralluri@223.229.181.84> has joined #yocto | 04:26 | |
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 04:28 | |
*** ralluri <ralluri!~ralluri@223.229.181.84> has quit IRC | 04:30 | |
*** ralluri <ralluri!~ralluri@223.229.181.84> has joined #yocto | 04:31 | |
*** ralluri <ralluri!~ralluri@223.229.181.84> has quit IRC | 04:36 | |
*** doerrpau1 <doerrpau1!~doerrpau@cpe-70-124-65-123.austin.res.rr.com> has quit IRC | 04:41 | |
*** ralluri <ralluri!~ralluri@223.229.181.84> has joined #yocto | 04:41 | |
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 05:12 | |
*** zeeblex <zeeblex!apalalax@nat/intel/x-uyrieusctwiamzlq> has joined #yocto | 05:20 | |
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 05:21 | |
*** agust <agust!~agust@pD9E2F88F.dip0.t-ipconnect.de> has joined #yocto | 05:41 | |
*** mihai <mihai!~mihai@192.198.151.44> has joined #yocto | 05:54 | |
*** ralluri <ralluri!~ralluri@223.229.181.84> has quit IRC | 06:10 | |
*** ka6sox is now known as ka6sox-away | 06:11 | |
*** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 06:31 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 06:35 | |
*** ralluri <ralluri!~ralluri@223.227.203.149> has joined #yocto | 06:36 | |
*** cristianiorga <cristianiorga!~cristiani@134.134.137.75> has joined #yocto | 06:39 | |
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 06:40 | |
*** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has joined #yocto | 06:41 | |
*** Saur1 <Saur1!pkj@nat/axis/x-xeffojlhkjontlrw> has joined #yocto | 06:44 | |
*** Saur <Saur!pkj@nat/axis/x-ctrtegclbovaourm> has quit IRC | 06:45 | |
*** francois99 <francois99!~francois9@78-33-60-6.static.enta.net> has joined #yocto | 06:45 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 06:48 | |
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto | 06:56 | |
*** ralluri <ralluri!~ralluri@223.227.203.149> has quit IRC | 07:11 | |
*** ralluri <ralluri!~ralluri@223.228.218.119> has joined #yocto | 07:20 | |
*** slaine <slaine!~slaine@84.203.137.218> has joined #yocto | 07:21 | |
*** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 07:22 | |
*** ralluri <ralluri!~ralluri@223.228.218.119> has quit IRC | 07:25 | |
*** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC | 07:25 | |
*** varjaaks <varjaaks!~ralluri@106.198.38.125> has joined #yocto | 07:26 | |
*** ralluri <ralluri!~ralluri@106.198.38.125> has joined #yocto | 07:26 | |
*** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 07:26 | |
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 07:27 | |
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has quit IRC | 07:27 | |
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto | 07:27 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 07:27 | |
*** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC | 07:28 | |
*** varjaaks <varjaaks!~ralluri@223.238.130.32> has joined #yocto | 07:28 | |
*** ralluri <ralluri!~ralluri@106.198.38.125> has quit IRC | 07:29 | |
ant_work | zecke: ping | 07:34 |
---|---|---|
*** lpapp <lpapp!~lpapp@212.44.19.228> has joined #yocto | 07:36 | |
zecke | ant_work: hi | 07:40 |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 07:40 | |
ant_work | hi | 07:41 |
ant_work | tests ok. I'll send you an email now | 07:41 |
zecke | ant_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_work | I've booted and run your binary | 07:42 |
ant_work | no issues (apart boot from mmc...) | 07:43 |
ant_work | I've sent you the ipk | 07:43 |
zecke | ant_work: thanks. https://lkml.org/lkml/2013/7/19/706 | 07:44 |
*** varjaaks <varjaaks!~ralluri@223.238.130.32> has quit IRC | 07:48 | |
*** ralluri <ralluri!~ralluri@223.238.130.32> has joined #yocto | 07:48 | |
*** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto | 07:48 | |
*** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto | 07:48 | |
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto | 07:50 | |
*** jonatan <jonatan!~quassel@194-237-7-146.customer.telia.com> has joined #yocto | 07:54 | |
*** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC | 07:55 | |
*** slaine <slaine!~slaine@84.203.137.218> has joined #yocto | 07:55 | |
*** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC | 07:56 | |
*** ralluri <ralluri!~ralluri@223.238.130.32> has quit IRC | 07:57 | |
*** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto | 08:01 | |
*** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto | 08:01 | |
*** bluelightning <bluelightning!~paul@83.217.123.106> has joined #yocto | 08:06 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 08:06 | |
lpapp | do you plan to have recipes-kde? | 08:07 |
*** sameo <sameo!samuel@nat/intel/x-drnvkwvfjowdxbcr> has joined #yocto | 08:10 | |
*** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has joined #yocto | 08:20 | |
*** ralluri <ralluri!~ralluri@106.198.56.96> has joined #yocto | 08:23 | |
bluelightning | morning all | 08:23 |
panda84kde | morning | 08:23 |
bluelightning | lpapp: http://layers.openembedded.org/layerindex/layer/meta-kde/ | 08:23 |
*** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC | 08:25 | |
lpapp | bluelightning: thanks | 08:26 |
*** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC | 08:26 | |
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has left #yocto | 08:26 | |
lpapp | bluelightning: 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 #yocto | 08:27 | |
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has joined #yocto | 08:27 | |
*** belen <belen!Adium@nat/intel/x-joougdfprvnoxqsn> has joined #yocto | 08:27 | |
bluelightning | lpapp: Sato is the GUI environment we use for testing basic X11 functionality | 08:28 |
bluelightning | lpapp: it's not a layer, it's part of OE-Core | 08:28 |
lpapp | bluelightning: yeah, it is recipes. | 08:28 |
*** b1gtuna_ <b1gtuna_!~adam@206.116.3.18> has quit IRC | 08:28 | |
lpapp | bluelightning: honestly, I have never heard about it and I have been using Linux for 10+ years. | 08:29 |
lpapp | bluelightning: is it some custom application by yocto/oe/poky? | 08:29 |
*** b1gtuna <b1gtuna!~adam@s206-116-3-18.bc.hsia.telus.net> has joined #yocto | 08:29 | |
panda84kde | lpapp: http://www.pokylinux.org/about/ | 08:29 |
panda84kde | it's a uber basic DE based on Matchbox WM | 08:30 |
bluelightning | lpapp: kind of, it's been around since 2007 at least | 08:30 |
*** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC | 08:30 | |
bluelightning | lpapp: the point is it's simple and provides a stable testbed for X11 | 08:30 |
panda84kde | plus an horrifying default green theme :) | 08:31 |
*** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto | 08:31 | |
*** Rootert <Rootert!~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto | 08:31 | |
ant_work | and doesn't fit on qvga | 08:32 |
lpapp | I really wonder why I have never heard this name before if it is such a good stuff. | 08:33 |
lpapp | probably very domain specific. | 08:34 |
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 08:35 | |
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 08:37 | |
*** varjaaks <varjaaks!~ralluri@106.198.56.96> has joined #yocto | 08:42 | |
*** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.85.234.195.229> has joined #yocto | 08:43 | |
*** varjaaks <varjaaks!~ralluri@106.198.56.96> has quit IRC | 08:43 | |
*** ralluri <ralluri!~ralluri@106.198.56.96> has quit IRC | 08:43 | |
*** fabo <fabo!~fabo@linaro/fabo> has joined #yocto | 08:46 | |
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 08:47 | |
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has left #yocto | 08:48 | |
*** ralluri <ralluri!~ralluri@223.228.122.184> has joined #yocto | 08:50 | |
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 08:50 | |
*** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 08:56 | |
*** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 08:57 | |
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 08:59 | |
eren | morning all | 09:05 |
fenrig | eren: morning ;) | 09:07 |
*** eren <eren!~eren@unaffiliated/eren> has quit IRC | 09:08 | |
*** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 09:09 | |
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 09:12 | |
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 09:13 | |
*** lpapp <lpapp!~lpapp@212.44.19.228> has quit IRC | 09:16 | |
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 09:16 | |
lpapp | can I specify the layers before the build? | 09:18 |
lpapp | I mean without creating a build folder. | 09:19 |
lpapp | I would like to set them more persistently. | 09:19 |
*** smartin__ <smartin__!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 09:20 | |
*** g0hl1n <g0hl1n!5be602f4@gateway/web/freenode/ip.91.230.2.244> has joined #yocto | 09:22 | |
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 09:23 | |
bluelightning | lpapp: 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 IRC | 09:25 | |
*** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has joined #yocto | 09:25 | |
*** vmeson <vmeson!~quassel@128.224.252.2> has quit IRC | 09:25 | |
*** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has joined #yocto | 09:26 | |
*** vmeson <vmeson!~quassel@128.224.252.2> has joined #yocto | 09:27 | |
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 09:28 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 09:30 | |
*** lyang01 <lyang01!~lyang001@1.202.252.122> has quit IRC | 09:30 | |
g0hl1n | Hello everyone | 09:34 |
g0hl1n | I've a problem installing iptables... | 09:34 |
g0hl1n | When 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 #yocto | 09:35 | |
g0hl1n | Does 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 #yocto | 09:36 | |
bluelightning | g0hl1n: sounds like your kernel configuration does not enable iptables/netfilter | 09:36 |
*** ralluri <ralluri!~ralluri@223.228.122.184> has quit IRC | 09:37 | |
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has joined #yocto | 09:37 | |
g0hl1n | bluelightning: I've set CONFIG_IP_NF_IPTABLES=y in my kernel config. Shouldn't that be enough? | 09:38 |
bluelightning | g0hl1n: what about CONFIG_IP_NF_FILTER ? | 09:45 |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 09:50 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 10:01 | |
*** ralluri <ralluri!~ralluri@223.228.122.184> has joined #yocto | 10:06 | |
*** diego <diego!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto | 10:14 | |
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC | 10:14 | |
*** diego is now known as Guest98519 | 10:14 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 10:15 | |
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 10:32 | |
lpapp | is there any documentation about "addtask" somewhere? | 10:32 |
g0hl1n | bluelightning: ok, that wasn't set in my config. I'll try it. | 10:33 |
*** ralluri <ralluri!~ralluri@223.228.122.184> has quit IRC | 10:34 | |
*** amarsman <amarsman!~marsman@84.241.214.153> has joined #yocto | 10:36 | |
*** roric <roric!~roric@194-237-7-146.customer.telia.com> has joined #yocto | 10:36 | |
*** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 10:38 | |
*** amarsman <amarsman!~marsman@84.241.214.153> has quit IRC | 10:43 | |
lpapp | is it an alright practice to create my own layer for our project, but only with the recipes folders we really need? | 10:45 |
lpapp | for instance if we need a more up-to-date u-boot, only recipes-bsp? | 10:45 |
lpapp | or it is better to replicate every recipes folders? | 10:45 |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 10:47 | |
*** arky <arky!~arky@113.22.64.132> has joined #yocto | 10:48 | |
ndec | lpapp: you just need to create the folders you need. no need to add 'empty' folders. | 10:48 |
arky | Is there a tutorial for webkiosk buildling ? Thanks | 10:49 |
lpapp | ndec: shall I copy the recipes.txt over, though? | 10:50 |
ndec | no. | 10:50 |
ndec | that file is in meta/ for reference. | 10:50 |
lpapp | yeah, I have just checked other layers not copying it . | 10:50 |
lpapp | though conf needs to be moved to a certain extent. | 10:51 |
ndec | in fact nothing really even forces you to follow recipes.txt in your own layer. | 10:51 |
ndec | you have to comply to it, if you intend to upstream some recipes in oe-core or meta-oe, though. | 10:51 |
ndec | conf? | 10:51 |
*** Guest98519 is now known as panda84kde | 10:52 | |
lpapp | ndec: the folder. | 10:52 |
ndec | you must have conf/layer.conf. that's what 'defines' a layer. | 10:53 |
ndec | beyond that, you are free to have whatever you need. | 10:53 |
lpapp | and I guess I need to disable the u-boot build from meta/recipes-bsp? | 10:54 |
ndec | no. | 10:54 |
ndec | either your recipe 'overrides' the original one, with for example a different version. | 10:54 |
lpapp | ah, ok. I guess it is based on priority? | 10:55 |
ndec | or you can use a different recipe name, and tell OE to use that one instead. | 10:55 |
lpapp | but then, how can one get both built? | 10:55 |
lpapp | equal priority? | 10:55 |
ndec | do you want both built? | 10:55 |
lpapp | I can imagine scenarios where it would be needed, yes. | 10:56 |
lpapp | not in my particular case, but in other scenarios. | 10:56 |
ndec | u-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 |
ndec | not different version of the same recipe | 10:57 |
lpapp | k | 10:57 |
*** flynn378 <flynn378!~AndChat27@75.76.29.10> has quit IRC | 10:58 | |
*** mihai <mihai!~mihai@192.198.151.44> has quit IRC | 10:58 | |
ndec | well, 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 |
lpapp | ndec: what about meta-foo/conf/bar-local.conf? | 10:59 |
ndec | what do you mena? | 10:59 |
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto | 10:59 | |
ndec | mean? | 10:59 |
*** mihai <mihai!~mihai@192.198.151.43> has joined #yocto | 11:00 | |
lpapp | meta-foo: own layer | 11:00 |
lpapp | bar-local.conf: config file for that own layer | 11:00 |
lpapp | we have such a conf file now in meta-yocto/conf/ | 11:00 |
lpapp | this is probably a bad practice, and I need to move it onto meta-foo | 11:00 |
lpapp | well, it might not be a bad practice | 11:00 |
lpapp | but I guess I need the same conf in both layers? | 11:00 |
*** ralluri <ralluri!~ralluri@27.61.40.159> has joined #yocto | 11:01 | |
ndec | i am not sure i understand what information you put in this conf file. | 11:01 |
bluelightning | lpapp: the idea is you should have your customisations in a distro config - conf/distro/distroname.conf | 11:01 |
*** varjaaks <varjaaks!~ralluri@27.61.40.159> has joined #yocto | 11:01 | |
bluelightning | lpapp: then you set DISTRO = "distroname" in local.conf and you've then enabled that set of configuration | 11:02 |
*** swex__ <swex__!~swex@178.132.101.134> has joined #yocto | 11:02 | |
bluelightning | lpapp: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-your-own-distribution | 11:02 |
lpapp | bluelightning: distro is poky. | 11:03 |
lpapp | with only slight mods. | 11:03 |
lpapp | like kernel adaptation for our board. | 11:03 |
lpapp | and custom u-boot. | 11:03 |
*** swex_ <swex_!~swex@217.197.255.96> has quit IRC | 11:05 | |
lpapp | although, yeah... we have our foo.conf and foo-tiny.conf | 11:06 |
lpapp | it is confusing to me though that poky-tiny includes poky, and not the other way around. | 11:06 |
lpapp | shouldn't the "more complete" extend the tiny? | 11:07 |
ndec | it's the otherway around. poky tiny is a customized poky with minimal config. | 11:08 |
bluelightning | lpapp: if you're changing anything you should really create your own distro config | 11:08 |
ndec | lpapp: 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 |
lpapp | bluelightning: so every minor change means a different distribution then? | 11:10 |
lpapp | including a one-liner patch? | 11:10 |
bluelightning | lpapp: no, it's just that for embedded applications it's pretty rare for people to want only one change | 11:11 |
ndec | it depends on the one-liner patch ;-) | 11:11 |
lpapp | bluelightning: then I am lost. | 11:11 |
lpapp | bluelightning: we only have some kernel hardware adaptation, but that is pretty much it. | 11:11 |
lpapp | and obviously, u-boot is also hardware specific, so we need to adapt that, too. | 11:12 |
lpapp | everything else is the same as in poky. | 11:12 |
bluelightning | lpapp: you have a foo.conf file you are including right now, is that correct? what does that have in it? | 11:12 |
lpapp | depends on what you mean by foo.cong. | 11:12 |
lpapp | conf* | 11:12 |
ndec | you mentioned it | 11:13 |
ndec | <lpapp> although, yeah... we have our foo.conf and foo-tiny.conf | 11:13 |
lpapp | I mentioned other foo.conf before, too. | 11:13 |
lpapp | in conf. | 11:13 |
bluelightning | as 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 machine | 11:15 |
lpapp | PREFERRED_VERSION_ubev ?= "141" -> this must be a typo, can you confirm that | 11:15 |
lpapp | I guess it should have been "udev". | 11:15 |
lpapp | from the look of it. | 11:16 |
bluelightning | yep looks like a typo | 11:16 |
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto | 11:16 | |
lpapp | bluelightning: what about that best practice? | 11:16 |
lpapp | adaptation means a new distribution? | 11:16 |
bluelightning | then, 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 config | 11:16 |
lpapp | for exactly the same package versions with adaptation patches? | 11:16 |
bluelightning | that 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 go | 11:17 |
*** ralluri <ralluri!~ralluri@27.61.40.159> has quit IRC | 11:17 | |
*** varjaaks <varjaaks!~ralluri@27.61.40.159> has quit IRC | 11:17 | |
bluelightning | lpapp: adaptation to your machine, no | 11:17 |
bluelightning | lpapp: any other customisations that are specific to your usage of the machine as opposed to the machine itself, yes | 11:17 |
bluelightning | bbl | 11:17 |
*** arky <arky!~arky@113.22.64.132> has quit IRC | 11:18 | |
*** ralluri <ralluri!~ralluri@223.228.31.5> has joined #yocto | 11:20 | |
lpapp | bluelightning: right, so a different version of u-boot yields a different distribution, right? | 11:25 |
lpapp | bluelightning: the distribution files should not go into the meta-yocto layer, right? | 11:25 |
lpapp | bluelightning: we do not need this stuff either, right? PREFERRED_VERSION_linux-yocto* | 11:27 |
lpapp | but perhaps PREFERRED_VERSION_linux-foo* instead, or not even that? | 11:27 |
*** arky <arky!~arky@113.22.26.168> has joined #yocto | 11:31 | |
*** mihai <mihai!~mihai@192.198.151.43> has quit IRC | 11:31 | |
lpapp | this should also go into the own layer? ../meta/recipes-core/psplash/files/psplash-foo-img.h | 11:33 |
*** mihai <mihai!mihai@nat/intel/x-djmzjbioktuojuyy> has joined #yocto | 11:33 | |
*** tbn <tbn!~tbn@mad27-1-88-172-46-29.fbx.proxad.net> has joined #yocto | 11:39 | |
*** tbn is now known as Guest76964 | 11:40 | |
*** joeythesaint <joeythesaint!~jjm@128.224.252.2> has joined #yocto | 11:50 | |
lpapp | BBFILE_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 |
lpapp | i.e. it is not describing why a "match" has to happen. | 11:57 |
*** amarsman <amarsman!~marsman@84.241.214.153> has joined #yocto | 12:01 | |
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto | 12:09 | |
*** ralluri <ralluri!~ralluri@223.228.31.5> has quit IRC | 12:18 | |
bluelightning | lpapp: 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-related | 12:19 |
bluelightning | lpapp: you'd create your own distro layer and not put those files in meta-yocto, correct | 12:19 |
bluelightning | lpapp: PREFERRED_VERSION is only useful if you want to make a selection between multiple available versions where those exist | 12:20 |
bluelightning | lpapp: a match has to happen in order for bitbake to find any recipes or bbappend files | 12:20 |
bluelightning | lpapp: it is only through BBFILES and BBFILE_PATTERN that that can occur | 12:21 |
*** amarsman <amarsman!~marsman@84.241.214.153> has quit IRC | 12:21 | |
lpapp | bluelightning: but if I do not need distro-related stuff, just machine, I am lost. | 12:21 |
lpapp | it is more accurate to call it a "bsp layer" rather than "distro layer"? | 12:21 |
bluelightning | lpapp: in that case feel free to not create a distro layer, no need to be lost :) | 12:21 |
bluelightning | lpapp: BSP layer and distro layer are different things | 12:22 |
bluelightning | lpapp: a BSP is for supporting your specific machine | 12:22 |
lpapp | bluelightning: yes, that is why I prefer the "bsp layer" term. | 12:22 |
bluelightning | lpapp: a distro layer is for configuration/customisations that are not specific to the machine, rather the use the machine is put to | 12:22 |
*** volker <volker!~volker@host-80-81-19-29.customer.m-online.net> has joined #yocto | 12:23 | |
lpapp | in which case, conf/distro is kinda moot. | 12:23 |
lpapp | we are fine with poky on this machine. | 12:23 |
lpapp | we only need the bsp adaptation. | 12:23 |
lpapp | at least for now, that is. | 12:23 |
bluelightning | then, feel free to stick to it :) | 12:23 |
lpapp | well, I do not see much difference, really. | 12:23 |
lpapp | except the fact, I would not have conf/distro/foo.conf | 12:23 |
lpapp | but to be honest, I do not mind having that either. | 12:24 |
lpapp | it is not the main question to me. | 12:24 |
bluelightning | if you're not providing a custom distro config you don't need conf/distro in your custom layer | 12:25 |
lpapp | bluelightning: I still do not understand the point of BBFILE_PATTERN | 12:25 |
lpapp | what additional benefit does it bring compared to BBFILES? | 12:25 |
*** amarsman <amarsman!~marsman@84.241.214.153> has joined #yocto | 12:25 | |
lpapp | bluelightning: 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 |
lpapp | so we have got to stick to poky, I am afraid. | 12:26 |
bluelightning | lpapp: that's totally fine | 12:26 |
*** amarsman <amarsman!~marsman@84.241.214.153> has quit IRC | 12:26 | |
lpapp | so, how is yocto different to mer/sailfish os? | 12:26 |
lpapp | oe/yocto to mer/sailfish? | 12:26 |
bluelightning | lpapp: 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 paths | 12:27 |
bluelightning | lpapp: feel free to consider it boilerplate for your layer.conf | 12:27 |
bluelightning | lpapp: I have very little experience with either of those | 12:27 |
lpapp | bluelightning: I think BBFILE_PATTERN is useless. | 12:28 |
lpapp | not now, but the concept. | 12:28 |
lpapp | I mean, you seem to filter in two-layers instead of one. | 12:28 |
lpapp | 1) You specify a list | 12:28 |
lpapp | 2) Then you filter the list | 12:28 |
lpapp | how about this instead: | 12:28 |
lpapp | 1) Use a proper filter list? | 12:28 |
bluelightning | lpapp: how would that look exactly? | 12:29 |
lpapp | custom splash would also go into the bsp layer? | 12:29 |
volker | is 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 slow | 12:30 |
ndec | volker: 'git grep' is your friend. | 12:31 |
ant_work | lpapp: only an almost empty .bbappend and the logo-image..h | 12:31 |
bluelightning | lpapp: 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 machine | 12:31 |
volker | ndec: but then I have to do git grep for every single repository if I checked out several layers from different vendors | 12:31 |
bluelightning | volker: indeed, "git grep" works well for me | 12:32 |
ant_work | lpapp: but yes, better to keep it distro-specific | 12:32 |
volker | under angstrom distribution the meta layer directories were placed under "source" so you could just limit the search to this directory | 12:32 |
lpapp | bluelightning: can I have the bsp and distro layer together? | 12:32 |
ndec | volker: i generally use 'repo' then to manage multiple trees. then 'repo grep' would become your friend ;-) | 12:32 |
lpapp | bluelightning: something like meta-ti? | 12:32 |
lpapp | or I should separate them? | 12:32 |
volker | ndec: 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 cents | 12:33 |
ant_work | lpapp: better to keep a logical separation. In fact only the recipes in the BSP layers are machine-specific | 12:34 |
*** lh <lh!lh@osuosl/staff/lh> has quit IRC | 12:34 | |
ant_work | lpapp: you hit a bad example... | 12:34 |
lpapp | ant_work: why? | 12:35 |
bluelightning | lpapp: best practice is to keep them separate; the idea is you can switch out your BSP layer without losing your customisations | 12:35 |
ant_work | other distros/people could be interested and reuse your generic layer | 12:35 |
bluelightning | lpapp: they can of course appear in the same repo if that helps | 12:35 |
lpapp | those are tight together for the next 10 years | 12:35 |
lpapp | or so. :) | 12:35 |
lpapp | so imo, separating them might be complication only. | 12:36 |
lpapp | what about the meta/recipes-foo? | 12:37 |
ant_work | lpapp: we use a modified linux-yocto-tiny kernel from oe-core passing through two more layers | 12:37 |
lpapp | should that go into the meta-$distro? | 12:37 |
lpapp | so? | 12:37 |
lpapp | it is a different use case. | 12:37 |
lpapp | they are not tied together in your scenario. | 12:37 |
lpapp | so there must be some flexibility. | 12:37 |
lpapp | it is not much so in my corporate case. | 12:38 |
ant_work | it's just a bit more burden for maintanance, not so much | 12:38 |
ant_work | you have one layer as common software collection / distro and one BSP for each SOC/machine you'd need in future | 12:39 |
lpapp | as I said, it is not like that. | 12:39 |
lpapp | there will be one hardware with one distro for the next one decade or so | 12:39 |
lpapp | try to decouple your mind from general open source stuff... ;) | 12:40 |
ant_work | then flatten all down if you feel more comfortable with it | 12:40 |
bluelightning | lpapp: 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 |
bluelightning | lpapp: 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 IRC | 12:49 | |
*** challinan <challinan!~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has joined #yocto | 12:50 | |
lpapp | bluelightning: trust me. :) | 12:58 |
lpapp | I know the business deal more... ;) | 12:58 |
lpapp | btw, 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=denzil | 12:59 |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-ijzkeiaqbbkoefwd> has joined #yocto | 12:59 | |
*** bluelightning_ <bluelightning_!~paul@83.217.123.106> has joined #yocto | 12:59 | |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 12:59 | |
lpapp | btw, how can I view the splash screen out of a header file provided to Yocto? | 12:59 |
lpapp | is there some generator for it? | 12:59 |
JaMa | sgw1: 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 queue | 13:00 |
JaMa | "gst-plugins-bad: add few more PACKAGECONFIGs" | 13:00 |
lpapp | bluelightning: btw, do I need a .bbappend for the splash screen, too? | 13:01 |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 13:02 | |
lpapp | BBLAYERS 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 |
lpapp | is there a more elegant way? | 13:03 |
lpapp | I cannot believe it is the right way for each build. :) | 13:03 |
lpapp | is there a more "catch-all" place? | 13:03 |
*** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 13:04 | |
lpapp | also, 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 #yocto | 13:28 | |
ndec | bluelightning_: 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 |
ndec | and this isn't quite nice, nor good. | 13:29 |
lpapp | how can I clean up the build folder? | 13:29 |
lpapp | I cannot just rm -rf it, as I need to keep the bblayers config file around... | 13:29 |
ndec | with the new backported patch, the headers files are set properly, when X11 isnt' there. | 13:29 |
ndec | bluelightning_: the culprit is EGL/eglplatform.h | 13:30 |
ndec | so 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 |
ndec | i 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 #yocto | 13: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 |
ndec | ok. and btw, the commit message was copy/paste from the commit in master ;-) | 13:31 |
ndec | i 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 |
ndec | i will resent today. | 13:32 |
bluelightning_ | ndec: thanks | 13: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 |
lpapp | also, 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 #yocto | 13:41 | |
*** dv_ <dv_!~quassel@chello080108009040.14.11.vie.surfer.at> has quit IRC | 13:41 | |
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 13:45 | |
*** tbn_ <tbn_!~tbn@84.55.160.118> has joined #yocto | 13:46 | |
ndec | lpapp: 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 |
lpapp | ndec: in which layer, and why? | 13:46 |
ndec | in your BSP layer. | 13:46 |
lpapp | why not just u-boot with higher priority than oe-core? | 13:47 |
ndec | why? unless you can reuse uboot from OE, as it is, and you only need minor tweak which can go into bbappend. | 13:47 |
ndec | but most of the time uboot really needs to be customized for the target h/w, sometimes with a vendor tree, ... | 13:47 |
ndec | in which case it's easier to go with your own recipe. | 13:47 |
* lpapp does not follow | 13:47 | |
ndec | so first, .bbappends is not appropriate for newer version of recipe. .bbappends is to 'overlay' an existing pair of recipe/version. | 13:48 |
lpapp | yes | 13:49 |
lpapp | agree | 13:49 |
ndec | and 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 |
lpapp | we do. | 13:49 |
*** Guest76964 <Guest76964!~tbn@mad27-1-88-172-46-29.fbx.proxad.net> has quit IRC | 13:49 | |
lpapp | we have one custom patch. | 13:50 |
lpapp | I think that is what people should do. | 13:50 |
ndec | so, if you have a minor patch/tweak *and* you use the uboot version that is in OE already, then, .bbappend is appropriate. | 13:51 |
lpapp | no, oe-core has an overly outdated version. | 13:51 |
ndec | but 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 |
lpapp | that means what? | 13:52 |
ndec | if you use a .bbappend in your layer, you reply on the .bb in OE, you agree? | 13:52 |
lpapp | yes, but that is not the main question in here. | 13:52 |
lpapp | I was wondering why I would need u-boot-lpapp instead of u-boot. | 13:52 |
ndec | so if OE .bb file changes to newer version, you are impacted. | 13:52 |
ndec | if you use a vendor tree for example. | 13:53 |
ndec | if what you need is too much different from uboot from OE. then you make yours. | 13:53 |
lpapp | not sure I follow. | 13:53 |
lpapp | the priority is set to my layer. | 13:53 |
lpapp | so I would not be any affected. | 13:53 |
lpapp | and that does not require lpapp suffix. | 13:53 |
ndec | if you use .bbappend, the priority doesn't matter. | 13:54 |
lpapp | well, we would not like to differ much from upstream. | 13:54 |
lpapp | it would be nice to have the patch always updated to the latest upstream version. | 13:54 |
lpapp | you 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 IRC | 13:55 | |
ndec | i 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 |
lpapp | I still do not understand why | 13:57 |
lpapp | it is u-boot after all. | 13:58 |
*** simon_b <simon_b!c06dbe58@gateway/web/freenode/ip.192.109.190.88> has joined #yocto | 13:58 | |
simon_b | Hello | 13:58 |
lpapp | it is not a forked u-boot. | 13:58 |
simon_b | I 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 |
ndec | then, 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 |
lpapp | ndec: we have one custom patch on top of u-boot upstream. | 13:59 |
*** icanicant <icanicant!~klawson@195.88.236.129> has quit IRC | 13:59 | |
lpapp | ndec: similar to something when desktop distributions have custom distro specific patches. | 13:59 |
lpapp | but they do not fork the packages. | 13:59 |
ndec | yes, you said that a couple of times. | 13:59 |
lpapp | yes, a patch is not a fork. | 13:59 |
dzoe | Hi (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 |
lpapp | we still update our changes based on upstream. | 14:00 |
lpapp | btw, is there an option for automatically updating the sha1 and md5? | 14:00 |
dzoe | Should 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 |
ndec | lpapp: well, desktop distro do make fork in reality. | 14:00 |
ndec | but that's not the point of our discussion.. | 14:00 |
lpapp | no, they do not fork. | 14:01 |
simon_b | oh: 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 image | 14:01 |
*** ka6sox-away is now known as ka6sox | 14:01 | |
simon_b | dlt-daemon.systemd -> dlt-daemon-systemd | 14:01 |
lpapp | I think for makepkg (archlinux), we had an option for automatically updating the checksum in the pkgbuild file. | 14:04 |
lpapp | is 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 work | 14:07 | |
*** arky <arky!~arky@113.22.48.5> has joined #yocto | 14:07 | |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 14:09 | |
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto | 14:09 | |
*** icanicant <icanicant!~klawson@195.88.236.129> has joined #yocto | 14:11 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 14:14 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 14:14 | |
*** simon_b <simon_b!c06dbe58@gateway/web/freenode/ip.192.109.190.88> has quit IRC | 14:17 | |
ant_work | lpapp: it even spits you the expected checksum. It's up to a human to decide if the tarball is corrupted or not | 14:20 |
*** roric <roric!~roric@194-237-7-146.customer.telia.com> has quit IRC | 14:21 | |
*** jonatan <jonatan!~quassel@194-237-7-146.customer.telia.com> has quit IRC | 14:21 | |
*** sveinse <sveinse!~chatzilla@79.160.140.131> has joined #yocto | 14:23 | |
*** roric <roric!~roric@194-237-7-146.customer.telia.com> has joined #yocto | 14:25 | |
*** jonatan <jonatan!~quassel@194-237-7-146.customer.telia.com> has joined #yocto | 14:25 | |
sveinse | I 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 n00b | 14:26 | |
*** zeeblex <zeeblex!apalalax@nat/intel/x-uyrieusctwiamzlq> has left #yocto | 14:26 | |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 14:29 | |
*** belen <belen!Adium@nat/intel/x-joougdfprvnoxqsn> has quit IRC | 14:32 | |
*** belen <belen!~Adium@134.134.139.72> has joined #yocto | 14:36 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 14:36 | |
*** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has quit IRC | 14:37 | |
*** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.85.234.195.229> has quit IRC | 14:40 | |
*** belen <belen!~Adium@134.134.139.72> has quit IRC | 14:53 | |
*** davest <davest!Adium@nat/intel/x-unkplzpvucqlzukm> has joined #yocto | 14:53 | |
*** lh <lh!lh@gonzo.dicp.de> has joined #yocto | 14:57 | |
*** lh <lh!lh@osuosl/staff/lh> has joined #yocto | 14:57 | |
*** hollisb <hollisb!~hollisb@nat-wv.mentorg.com> has joined #yocto | 14:58 | |
*** dv__ is now known as dv_ | 15:00 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-ijzkeiaqbbkoefwd> has quit IRC | 15:01 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-wqnyoxhfxwqmqseq> has joined #yocto | 15:03 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-wqnyoxhfxwqmqseq> has quit IRC | 15: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 buildhistory | 15:09 |
*** rburton_ <rburton_!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 15:09 | |
bluelightning_ | dzoe: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality | 15:10 |
bluelightning_ | dzoe: specifically the .dot graphs showing dependency information within the image | 15:10 |
dzoe | bluelightning_: 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 #yocto | 15:13 | |
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 15:14 | |
dzoe | bluelightning_: 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 IRC | 15: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 #yocto | 15:15 | |
bluelightning_ | dzoe: so, the first thing is that there's a difference between what gets built and what gets included in the image | 15:15 |
*** belen <belen!~Adium@134.134.139.72> has joined #yocto | 15:15 | |
bluelightning_ | dzoe: I think what's been happening in your case is that avahi is being built but not included | 15: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-daemon | 15:16 |
bluelightning_ | dzoe: in order to be able to satisfy that, bitbake then must build avahi-daemon | 15:16 |
dzoe | bluelightning_: was included - I don't care about building it, that's okay, but it was in the image and was running after startup | 15:17 |
bluelightning_ | dzoe: OK, I wouldn't think it possible for that to be as a result of this recipe though | 15:18 |
*** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 15:20 | |
*** belen <belen!~Adium@134.134.139.72> has quit IRC | 15:21 | |
*** belen2 <belen2!Adium@nat/intel/x-vumytgetcbihabyx> has joined #yocto | 15:21 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 15:22 | |
*** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC | 15:28 | |
lpapp | bluelightning_: do you know if I can get the checksum updated automatically? | 15:29 |
*** arky <arky!~arky@113.22.48.5> has quit IRC | 15:30 | |
bluelightning_ | lpapp: automatically at what time? | 15:31 |
lpapp | bluelightning_: by running a command | 15:32 |
*** ralluri <ralluri!~ralluri@223.238.95.176> has quit IRC | 15:32 | |
lpapp | with Archlinux, I place the files into the current folder, and I run makepkg -G | 15:32 |
lpapp | and 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 difficult | 15:33 |
*** ralluri <ralluri!~ralluri@223.238.237.207> has joined #yocto | 15:35 | |
*** ralluri <ralluri!~ralluri@223.238.237.207> has joined #yocto | 15:36 | |
lpapp | bluelightning_: should be a bitbake option if you ask me. | 15:36 |
bluelightning_ | lpapp: bitbake doesn't ever modify its input files | 15:37 |
lpapp | bluelightning_: that should be changed, yes. | 15:37 |
bluelightning_ | no, it's a design decision; any such tool would need to be external | 15:37 |
lpapp | why ? | 15:37 |
lpapp | other tools have been doing that just fine. | 15:38 |
lpapp | and it is the most convenient way. | 15:38 |
bluelightning_ | lpapp: why would an external tool be a problem for this case? | 15:38 |
lpapp | it is such a common operation that external tools do not make sense IMHO. | 15:38 |
lpapp | it would be a problem because: | 15:38 |
lpapp | it 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 IRC | 15:39 | |
lpapp | bluelightning_: so? | 15:39 |
lpapp | I do not think we need a separate tool for one tiny option. | 15:39 |
lpapp | I would not like to run a separate command. | 15:40 |
dzoe | bluelightning_: I'll try to trace the dependencies closer later, but right now I have virtually no clue why it is happening | 15:40 |
bluelightning_ | lpapp: it's not just one tiny option, it's a change in how bitbake behaves with regard to its input metadata | 15:40 |
bluelightning_ | dzoe: the buildhistory image info should help you do that - I'd be interested in the results | 15:40 |
lpapp | bluelightning_: I do not follow | 15:41 |
*** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 15:41 | |
lpapp | bluelightning_: updating something is not editing. | 15:41 |
lpapp | although it is still source compilation related. | 15:41 |
lpapp | it is a minor stuff. | 15:41 |
bluelightning_ | lpapp: bitbake does not modify its input metadata, what you're talking about is modification | 15:41 |
lpapp | you could even tell bitbake update the md5sum before building | 15:41 |
lpapp | it really is bitbake scope. | 15:41 |
lpapp | bluelightning_: it is irrelevant what it does. | 15:41 |
lpapp | what matters in the end of the day, what is useful for end users. | 15:42 |
bluelightning_ | lpapp: sorry, but it is relevant | 15:42 |
lpapp | let us agree to disagree | 15: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 sources | 15:43 |
lpapp | bluelightning_: why would users use an option which is totally irrelevant for their use case? | 15:43 |
lpapp | it would not be an obligation of course. | 15:44 |
lpapp | and would not be default either | 15:44 |
lpapp | so I fail to understand the concern. | 15:44 |
lpapp | is there a devtool already? If not, I think it is an overkill to create one. | 15:47 |
lpapp | if yes, it could be added in there, too. | 15:47 |
*** TuTizz <TuTizz!~TuTizz@46.18.96.158> has quit IRC | 15:47 | |
*** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has joined #yocto | 15:51 | |
*** tbn_ <tbn_!~tbn@84.55.160.118> has quit IRC | 15:58 | |
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has quit IRC | 15:59 | |
*** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has quit IRC | 16:00 | |
lpapp | https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide -> for me, it is not clear where to put patches. | 16:00 |
lpapp | is there a dedicated variable for those, or I need to use the do_patches function? | 16:00 |
lpapp | I 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 IRC | 16:01 | |
*** mihai <mihai!mihai@nat/intel/x-djmzjbioktuojuyy> has quit IRC | 16:06 | |
eren | lpapp: what do you mean, released version? | 16:08 |
lpapp | eren: that one is fetching the git repository. | 16:08 |
lpapp | eren: 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 parse | 16:09 |
eren | I guess that explains it? | 16:09 |
eren | it's not a big problem, I guess | 16:09 |
lpapp | nope | 16:09 |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-gtfyocmcioldvwdy> has joined #yocto | 16:10 | |
lpapp | I do not understand the second line at all. | 16:10 |
*** nitink <nitink!~nitink@134.134.137.71> has joined #yocto | 16:10 | |
lpapp | well, it is a big problem. | 16:10 |
lpapp | because people might follow this wrong way. | 16:10 |
*** sveinse <sveinse!~chatzilla@79.160.140.131> has quit IRC | 16:11 | |
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC | 16:12 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-gtfyocmcioldvwdy> has quit IRC | 16:12 | |
lpapp | I think it is more elegant to fetch the tarball. | 16:13 |
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 16:13 | |
lpapp | which 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 IRC | 16:14 | |
lpapp | does that sound reasonable? | 16:14 |
eren | well, not at the moment :/ | 16:15 |
eren | probably we should ask it to more experienced people | 16:16 |
lpapp | ? | 16:16 |
lpapp | it should not be difficult to write a package to change the download url | 16:16 |
bluelightning_ | lpapp: you may find looking through the git history for that recipe might explain what's going on there | 16:16 |
lpapp | bluelightning_: I do not have a clone | 16:16 |
bluelightning_ | lpapp: patches are referred to in SRC_URI | 16:17 |
bluelightning_ | lpapp: as with all other source files fetched for the recipe | 16:17 |
lpapp | bluelightning_: yeah, so not a dedicated file like with dpkg. :( | 16:18 |
bluelightning_ | lpapp: no, everything is in the recipe | 16:18 |
lpapp | bluelightning_: I cloned, but git log does not mention anything useful. | 16:19 |
lpapp | I do not think a release package is worth not using the release tarball. | 16:19 |
lpapp | to me, it seems a bad packaging QA. | 16:19 |
lpapp | and should be revamped. | 16:19 |
lpapp | should be an oe-core change. | 16:20 |
lpapp | since 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 |
zibri | lpapp: what is the issue with fetching a tagged commit from git? | 16:20 |
zibri | it *is* the release | 16:21 |
eren | what's the difference between checking out the tag from which also the tarball is generated? | 16:21 |
lpapp | zibri: no, it is not. | 16:21 |
zibri | oh no? | 16:21 |
lpapp | zibri: check the project's website where the released stuff is coming from. | 16:21 |
lpapp | I will help you: | 16:21 |
zibri | i assume they don't tag random commits... but i don't know the u-boot release process ;) | 16:21 |
lpapp | ftp://ftp.denx.de/pub/u-boot/ | 16:22 |
*** pidge <pidge!pidge@nat/intel/x-nsvdonqtctqpdqzz> has joined #yocto | 16:22 | |
lpapp | well, the main desktop distributions do not work like this either. | 16:23 |
zibri | i *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 |
lpapp | also, what if they migrate to svn | 16:23 |
lpapp | or anything else. | 16:23 |
lpapp | really, it is a very bad decision packager made. | 16:23 |
zibri | then update the SRC_URI to svn instead of git? :) | 16:23 |
lpapp | or use a flexible and official way instead? | 16:23 |
lpapp | instead of carrying the crap? | 16:23 |
zibri | ... | 16:23 |
lpapp | tell me, what the u-boot download link tells you? | 16:24 |
lpapp | go to git and fetch? | 16:24 |
lpapp | or it gives the tarballs for downloading? | 16:24 |
eren | it provides you options, I believe there is no "right" way for this stuff | 16:24 |
eren | either clone the tag, or download tarball for this tag | 16:24 |
lpapp | where do you see "git clone" for download ? | 16:25 |
lpapp | to get the release? | 16:25 |
lpapp | could you please point me to the link? | 16:25 |
lpapp | there *is* right way | 16:25 |
zibri | lpapp: http://www.denx.de/wiki/U-Boot/SourceCode | 16:25 |
lpapp | which is the official way. | 16:25 |
zibri | first bullet point: git :) | 16:25 |
lpapp | zibri: nice misinterpretation try. | 16:25 |
lpapp | *** current *** source code | 16:26 |
zibri | as well as history? | 16:26 |
lpapp | they write with bold characters .... | 16:26 |
ndec | lpapp: well, the official release email says that we can download from git, or ftp. | 16:26 |
lpapp | for the fuck sake. | 16:26 |
zibri | argh, i give up | 16:26 |
lpapp | then the next bold line is: Released Versions (and some special snapshots) are available from the DENX FTP server | 16:26 |
eren | zibri: I give up, as well | 16:26 |
ndec | U-Boot v2011.06 has been released and is available from the git repository and the FTP server. | 16:26 |
ndec | http://lists.denx.de/pipermail/u-boot/2011-June/094956.html | 16:26 |
* lpapp is afraid of the oe/yocto packaging quality | 16:27 | |
*** JimNH3 <JimNH3!~jmchale@23-25-235-113-static.hfc.comcastbusiness.net> has joined #yocto | 16:28 | |
*** tomz <tomz!~trz@c-68-53-177-94.hsd1.in.comcast.net> has joined #yocto | 16:28 | |
*** tomz is now known as Guest91176 | 16:28 | |
eren | I believe we cannot judge packaging quality just by looking how it fetches source | 16:29 |
lpapp | oh yeah, sure, desktop distributions having a lot more packaging experience are all stupid | 16:29 |
ndec | lpapp: debian packaging for u-boot: http://anonscm.debian.org/gitweb/?p=collab-maint/u-boot.git;a=commit;h=b1af6f532e0d348b153d5c148369229d24af361a | 16:30 |
lpapp | and perhaps Yocto is the right thing. | 16:30 |
ndec | they import the entire git history of the project. | 16:30 |
ndec | it's even the very same commit SHA1 as in OE. | 16:30 |
kergoth | zibri: Use /ignore, I've felt better ever since :) | 16:30 |
ndec | i think we can consider debian, as a decent desktop distro. | 16:30 |
eren | ndec: debian as a "decent" desktop distro? | 16:31 |
eren | hm :) | 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 IRC | 16:31 | |
eren | hehehe :P | 16:31 |
eren | we need to define "decent" actually | 16:32 |
eren | but it would be off-topic here | 16:32 |
zibri | kergoth: :) | 16:32 |
ndec | i have the feeling there is a lot of off-topic today ;-) | 16:33 |
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 16:34 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 16:34 | |
lpapp | ndec: https://aur.archlinux.org/packages/ub/uboot-mkimage/PKGBUILD | 16:34 |
lpapp | yay, they are not dependent on the VCS? | 16:35 |
lpapp | they use the official way from the website? | 16:35 |
ndec | lpapp: and? that basically means that there is choice around. and it's good. | 16:35 |
lpapp | no | 16:35 |
lpapp | it means, they do not depend on the vcs, tag, server, whatever. | 16:36 |
lpapp | and they use the official way written on the website. | 16:36 |
eren | but the developers of u-boot depend on vcs, tag, server, whatever to actually produce that tarball? :) | 16:36 |
lpapp | and it also means they are not inconsistent unlike yocto and oe | 16:36 |
lpapp | like few packages come from git, the other from tarball urls, etc. | 16:36 |
lpapp | eren: developers != packagers. | 16:37 |
lpapp | also, pass mistakes are hardly excuse for introducing more. | 16:37 |
lpapp | I am sure the debian developers would appreciate contribution in this regard in line with their policies. | 16:38 |
lpapp | also, if the history of the repository is modified, they also screws up the downstream packages, etc. | 16:39 |
lpapp | that* | 16:40 |
lpapp | again, I am surprised by the packaging quality. | 16:40 |
lpapp | the 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 #yocto | 16:41 | |
lpapp | but then, git will not work either anyway | 16:41 |
*** myopiate <myopiate!~myopiate@203.206.170.6> has quit IRC | 16:43 | |
*** myopiate <myopiate!~myopiate@203-206-170-6.perm.iinet.net.au> has joined #yocto | 16:44 | |
*** eren <eren!~eren@unaffiliated/eren> has quit IRC | 16:44 | |
lpapp | from the debian mentor channel: | 16:45 |
lpapp | 17:41 < lpapp> hi, is it ok to package something from git for a stable release? | 16:45 |
lpapp | 17:41 < lpapp> or should we try to use the released tarball with the url coming from the website. | 16:45 |
lpapp | 17:42 < SamB> it's better if you can use a release, yes | 16:45 |
lpapp | 17:44 < SamB> and if upstream distributes release tarballs you should indeed use those rather than roll your own | 16:46 |
lpapp | ndec: so, no, you cannot consider that debian package "decent". | 16:46 |
lpapp | is 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 #yocto | 16:55 | |
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC | 16:56 | |
bluelightning_ | lpapp: not to my knowledge, unless there's something provided in the psplash code | 16:57 |
lpapp | bluelightning_: so how can one generate "image headers"? | 16:57 |
lpapp | it is pretty strange to have something like this. | 16:57 |
lpapp | is it Yocto specific? | 16:57 |
bluelightning_ | lpapp: it's psplash-specific | 16:57 |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-jfktefpysnckwnqr> has joined #yocto | 16:58 | |
bluelightning_ | lpapp: you can supply your own png in the SPLASH_IMAGES variable | 16:58 |
lpapp | no no, we use headers. | 16:58 |
bluelightning_ | it'll be converted automatically as part of the build | 16:58 |
lpapp | try to open that up with an image viewer ... | 16:58 |
lpapp | say, 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 source | 16:58 |
lpapp | what script? | 16:59 |
lpapp | btw, psplash seems to be a yocto project, so it is relevant to Yocto. | 17:00 |
lpapp | kinda domain specific. | 17:00 |
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 17:00 | |
bluelightning_ | lpapp: https://git.yoctoproject.org/cgit/cgit.cgi/psplash/tree/make-image-header.sh | 17:00 |
bluelightning_ | if you prefer you can always use your own splashscreen application | 17:01 |
bluelightning_ | or, none at all | 17:01 |
lpapp | bluelightning_: that script does not even have a help menu ... | 17:02 |
bluelightning_ | lpapp: it's not ideal I'll admit | 17:03 |
bluelightning_ | I'm sure patches would be welcome | 17:03 |
lpapp | bluelightning_: can you summarize how it must be used? | 17:03 |
lpapp | from 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 IRC | 17:04 | |
lpapp | 18:02 < hofstee> lpapp: tarball seems more logical since you don't need the history, and tag and tarball should be equal | 17:04 |
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 17:04 | |
lpapp | just like I claimed several times above ... | 17:05 |
lpapp | I even offered the help with updating it... but it was not too much appreciated. | 17:05 |
lpapp | guess whether I help with it ... | 17:05 |
*** silviof2 <silviof2!~silviof@ppp-188-174-104-55.dynamic.mnet-online.de> has quit IRC | 17:05 | |
lpapp | ndec: also, they do *not* use git for debian | 17:06 |
lpapp | ndec: 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 different | 17:06 |
lpapp | See? I would like to contribute, and then I am said "hung up" | 17:07 |
lpapp | "better to ignore me" etc | 17:07 |
lpapp | (this is not the first time for offering contribution for _free_) | 17:07 |
lpapp | to me, it seems awkward one needs to fight to be able to help. | 17:08 |
lpapp | even over minor and trivial things. | 17:10 |
lpapp | I kinda expected, "sure, go ahead, that would be great!" | 17:10 |
lpapp | I 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 same | 17:11 |
lpapp | you can say that against everyone else | 17:12 |
lpapp | arch, debian packagers, u-boot authors, etc. | 17:12 |
lpapp | if you do not care about what upstream suggests, probably it is not my cup of tea to contribute here. | 17:13 |
lpapp | we 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 |
lpapp | everyone else said: tarball is preferred. | 17:14 |
lpapp | there is technically hardly any reason to go against everyone else. | 17:14 |
lpapp | anyway, 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 release | 17:14 |
lpapp | surely, I am not willing to submit it upstream anymore | 17:14 |
lpapp | except that, it is pretty much the same. | 17:15 |
*** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC | 17:24 | |
lpapp | bluelightning_: I asked several times for qt issues last time, but I did not get anything. | 17:25 |
lpapp | I 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 everything | 17:26 |
lpapp | bluelightning_: no, I asked for reasons apart from the sdk why it is not mature | 17:26 |
lpapp | and I have not got any reasons really. | 17:26 |
lpapp | just that "3 months is not enough to make it" | 17:26 |
lpapp | bluelightning_: 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 IRC | 17:28 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 17:28 | |
bluelightning_ | I have a meeting now unfortunately, bbl | 17:29 |
*** bluelightning1 <bluelightning1!~paul@83.217.123.106> has joined #yocto | 17:32 | |
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 17:33 | |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 17:34 | |
*** belen2 <belen2!Adium@nat/intel/x-vumytgetcbihabyx> has quit IRC | 17:40 | |
lpapp | bluelightning1: 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 IRC | 17:52 | |
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 17:53 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-jfktefpysnckwnqr> has quit IRC | 17:57 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-whupydfoovlyegra> has joined #yocto | 18:00 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 18:00 | |
bluelightning | lpapp: 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 support | 18:02 |
*** bluelightning1 <bluelightning1!~paul@83.217.123.106> has quit IRC | 18:02 | |
bluelightning | lpapp: 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 being | 18:02 |
bluelightning | lpapp: with regard to where to put patches / configuration it depends on whether your change makes sense mostly just for your case or for all users | 18:04 |
*** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 18:07 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 18:26 | |
*** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC | 18:29 | |
*** joeythesaint <joeythesaint!~jjm@128.224.252.2> has quit IRC | 18:30 | |
lpapp | oh, bluelightning has just left. | 18:37 |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-whupydfoovlyegra> has quit IRC | 18:38 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-hfanxvxaigfyynlp> has joined #yocto | 18:41 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-hfanxvxaigfyynlp> has quit IRC | 18:46 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 18:46 | |
*** varjaaks <varjaaks!~ralluri@223.228.59.211> has joined #yocto | 18:55 | |
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 18:57 | |
*** ralluri <ralluri!~ralluri@223.238.237.207> has quit IRC | 18:58 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-cozoqtitntgkeljb> has joined #yocto | 19:07 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-cozoqtitntgkeljb> has quit IRC | 19:08 | |
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC | 19:15 | |
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto | 19:18 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 19:19 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-fkllnjfsvjxgapae> has joined #yocto | 19:19 | |
*** likewise <likewise!~chatzilla@ip503cba31.speed.planet.nl> has joined #yocto | 19:25 | |
*** yzhao2_ <yzhao2_!~yzhao2@128.224.252.2> has joined #yocto | 19:29 | |
*** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has quit IRC | 19:32 | |
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC | 19:37 | |
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 19:39 | |
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto | 19:41 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 19:42 | |
*** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC | 19:45 | |
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC | 19:46 | |
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC | 19:47 | |
*** joeythesaint <joeythesaint!~jjm@206-248-190-39.dsl.teksavvy.com> has joined #yocto | 19:54 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-fkllnjfsvjxgapae> has quit IRC | 19:56 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-klbwlqcsweydnpth> has joined #yocto | 19:59 | |
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has quit IRC | 20:10 | |
sgw1 | Hi 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 |
yocti | Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4854 normal, Medium, ---, raj.khem, NEW , floor call (from math.h) is broken on qemuppc | 20:15 |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 20:20 | |
*** silviof2 <silviof2!~silviof@ppp-93-104-17-108.dynamic.mnet-online.de> has joined #yocto | 20:28 | |
*** bluelightning <bluelightning!~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com> has joined #yocto | 20:29 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 20:29 | |
lpapp | bluelightning: welcome back | 20:36 |
*** likewise <likewise!~chatzilla@ip503cba31.speed.planet.nl> has quit IRC | 20:37 | |
bluelightning | hi | 20:40 |
lpapp | bluelightning: what did you write last? | 20:40 |
* kergoth tries to whittle down the dependencies necessary to build systemd-tmpfiles | 20:40 | |
*** trollixx_ <trollixx_!~trollixx@sf.wisetroll.net> has quit IRC | 20:41 | |
*** trollixx <trollixx!~trollixx@sf.wisetroll.net> has joined #yocto | 20:41 | |
bluelightning | lpapp: http://logs.nslu2-linux.org/livelogs/yocto.txt | 20:42 |
lpapp | hmm, this channel is publically logged, and not mentioned in the topic? | 20:43 |
bluelightning | I think it says "you may wish to" | 20:45 |
lpapp | the freenode rule is to mention it if I recall correctly. | 20:46 |
lpapp | bluelightning: our patches are hardware adaptation mostly. | 20:48 |
lpapp | to linux, u-boot, etc. | 20:48 |
bluelightning | so, it sounds like for the most part, they would be eminently suited for a BSP layer | 20:50 |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-klbwlqcsweydnpth> has quit IRC | 20:51 | |
b1gtuna | Good afternoon everybody! | 20:51 |
b1gtuna | Is there a replacement of busybox? | 20:51 |
b1gtuna | Something more.. fully featured? | 20:51 |
lpapp | bluelightning: is there a good example for applying packages in case of any package? | 20:52 |
kergoth | yes, the real applications. | 20:52 |
kergoth | which are many | 20:52 |
lpapp | b1gtuna: coreutils | 20:52 |
b1gtuna | hm | 20:52 |
b1gtuna | ya replacing busybox with individual packages will take some time | 20:52 |
b1gtuna | lpapp: coreutils? | 20:52 |
bluelightning | lpapp: not sure I understand the question | 20:52 |
lpapp | b1gtuna: yes | 20:54 |
sgw1 | b1gtuna: 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 |
lpapp | bluelightning: ... for applying _patches_ ... | 20:54 |
kergoth | aha, 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 anymore | 20:54 | |
bluelightning | lpapp: sure, that's not the part I didn't understand though... | 20:54 |
*** sgw1 is now known as sgw_ | 20:54 | |
b1gtuna | lpapp sgw1 - sweet! configurable through DISTRO_FEATURES? | 20:55 |
sgw_ | kergoth: yeah, basic and lsb will help out. | 20:55 |
lpapp | bluelightning: I am looking for examples in the existing layers | 20:55 |
lpapp | bluelightning: how to do patching nicely. | 20:55 |
bluelightning | b1gtuna: it's just a packagegroup you'd add to your existing image | 20: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/images | 20:56 |
bluelightning | lpapp: the BSP guide should be a good starting reference | 20:56 |
bluelightning | bbl | 20:56 |
b1gtuna | bluelightning sgw_: makes sense. gracias! | 20:56 |
kergoth | gah, dumping the config.log files to the do_configure log is not cool | 20:57 |
kergoth | we need a variable to toggle that behavior | 20:57 |
kergoth | the end of the config.log is almost never of any use, its all the variables from the cache and crap | 20:57 |
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto | 20:57 | |
kergoth | gaaaaah | 21:06 |
kergoth | i hate when i lose patches i had forgot to copy out of ${S} | 21:07 |
kergoth | do a clean and time to do it over again | 21:07 |
kergoth | hmm, we really need to get the tmux terminal types fixed, i haven't had *any* time to look at it since it first got merged | 21:08 |
sgw_ | kergoth: been there done that too many times, we need a tool for that! | 21:13 |
kergoth | yes, indeed. push_my_patches_to_an_appropriate_path_in_filespath | 21:13 |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-dqrwxkrtntxkqngm> has joined #yocto | 21: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 |
kergoth | Honestly, I have no idea, I mostly punted and let mickey lauer handle python back in the day :) | 21:17 |
kergoth | it was unpleasant, as all the scripting language builds are | 21:17 |
sgw_ | kergoth: yeah, his name is in that file :-)! | 21:17 |
kergoth | :) | 21:18 |
kergoth | okay, 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 #yocto | 21:27 | |
kergoth | Does 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 |
kergoth | I'm thinking that may have been related to bug 3225 and tehrefore would have been resolved by the switch to the pr server | 21:33 |
yocti | Bug 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 switch | 21:33 |
kergoth | but I'm uncertain, and we may need a workaround/fix for dylan | 21:33 |
JaMa | yes that's the issue | 21:35 |
JaMa | now PR server contains package architecture, so if it's MACHINE_ARCH recipe then it's fine | 21:36 |
JaMa | key in PR server | 21:36 |
kergoth | okay, 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 server | 21:36 |
*** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has joined #yocto | 21:43 | |
*** darknighte_znc <darknighte_znc!~darknight@nat-lmt.mentorg.com> has joined #yocto | 21:54 | |
*** darknighte_znc is now known as darknighte | 21:55 | |
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto | 21:55 | |
*** sameo <sameo!samuel@nat/intel/x-lwgoirshupqopfxx> has joined #yocto | 21:57 | |
*** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 21:58 | |
*** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 21:59 | |
*** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has quit IRC | 22:11 | |
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-dqrwxkrtntxkqngm> has quit IRC | 22:16 | |
*** pidge <pidge!pidge@nat/intel/x-nsvdonqtctqpdqzz> has quit IRC | 22:19 | |
*** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 22:20 | |
*** zeddii <zeddii!~ddez@128.224.252.2> has quit IRC | 22:38 | |
*** vmeson <vmeson!~quassel@128.224.252.2> has quit IRC | 22:38 | |
*** vmeson <vmeson!~quassel@128.224.252.2> has joined #yocto | 22:40 | |
*** yzhao2_ <yzhao2_!~yzhao2@128.224.252.2> has quit IRC | 22:40 | |
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto | 22:42 | |
*** zeddii <zeddii!~ddez@128.224.252.2> has joined #yocto | 22:42 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 22:45 | |
*** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has joined #yocto | 22:47 | |
*** agust <agust!~agust@pD9E2F88F.dip0.t-ipconnect.de> has quit IRC | 22:52 | |
*** volker_ <volker_!~volker@host-80-81-19-29.customer.m-online.net> has joined #yocto | 22:54 | |
*** volker_ is now known as Guest68081 | 22:54 | |
*** davest <davest!Adium@nat/intel/x-unkplzpvucqlzukm> has quit IRC | 22:58 | |
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC | 23:00 | |
*** volker <volker!~volker@host-80-81-19-29.customer.m-online.net> has quit IRC | 23:00 | |
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC | 23:00 | |
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC | 23:00 | |
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 23:01 | |
*** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto | 23:01 | |
*** acidfu <acidfu!~nib@24.37.17.210> has joined #yocto | 23:01 | |
*** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto | 23:01 | |
*** ant_home <ant_home!~andrea@host133-7-dynamic.20-79-r.retail.telecomitalia.it> has quit IRC | 23:01 | |
*** sameo <sameo!samuel@nat/intel/x-lwgoirshupqopfxx> has quit IRC | 23:14 | |
*** ndec <ndec!~ndec@linaro/ndec> has quit IRC | 23:18 | |
*** ndec <ndec!~ndec@2001:41d0:8:e632::1> has joined #yocto | 23:18 | |
*** ndec <ndec!~ndec@linaro/ndec> has joined #yocto | 23:18 | |
*** _julian_ <_julian_!~quassel@x2f122e2.dyn.telefonica.de> has quit IRC | 23:24 | |
*** arky <arky!~arky@113.22.50.193> has joined #yocto | 23:26 | |
*** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 23:44 | |
*** arky <arky!~arky@113.22.50.193> has quit IRC | 23:45 | |
*** _julian <_julian!~quassel@x2f04625.dyn.telefonica.de> has joined #yocto | 23:50 | |
*** doerrpau <doerrpau!~doerrpau@cpe-70-124-65-123.austin.res.rr.com> has joined #yocto | 23:54 | |
*** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC | 23:56 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!