Tuesday, 2019-11-26

*** vineela <vineela!vtummala@nat/intel/x-unguqpgwpkqhyerm> has quit IRC00:10
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC00:14
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC00:17
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC00:18
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto00:25
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC00:26
*** tz <tz!~tz@orange.tzarc.io> has quit IRC00:27
*** learningc <learningc!~pi@121.122.85.48> has quit IRC00:38
*** kaspter <kaspter!~Instantbi@124.77.81.26> has quit IRC00:40
*** kaspter <kaspter!~Instantbi@222.67.188.174> has joined #yocto00:40
*** learningc <learningc!~pi@121.122.85.48> has joined #yocto00:40
*** tz <tz!~tz@orange.tzarc.io> has joined #yocto00:56
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC01:11
*** bjobjo <bjobjo!~bjobjo@2a01:79d:3e81:5208::9e6> has quit IRC01:12
*** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC01:36
*** kaspter <kaspter!~Instantbi@222.67.188.181> has joined #yocto01:36
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC01:43
*** kaspter <kaspter!~Instantbi@222.67.188.181> has quit IRC02:25
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto02:30
*** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC02:31
*** chandana73 <chandana73!~ckalluri@149.199.62.131> has quit IRC02:32
*** kaspter <kaspter!~Instantbi@101.93.194.160> has joined #yocto02:35
*** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto02:37
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC04:05
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto05:15
*** DvorkinDmitry <DvorkinDmitry!~Dvorkin@59-120-32-26.HINET-IP.hinet.net> has quit IRC05:26
*** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-pkzqeaeoukxeewim> has joined #yocto06:06
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto06:18
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto06:21
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto06:24
*** pohly <pohly!~pohly@p54BD5B80.dip0.t-ipconnect.de> has joined #yocto06:52
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto07:07
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC07:10
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto07:10
*** alessioigor <alessioigor!~alessioig@out-207-227.elettra.trieste.it> has quit IRC07:14
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:23
rcrudowhat is the recommended way to install systemd files? I need to install a network config file at /etc/systemd/network, but only for a specific distro07:26
LetoThe2ndrcrudo: make a recipe for it, simple as is07:27
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC07:27
rcrudohmm, ok. thanks07:30
*** alessioigor <alessioigor!~alessioig@out-207-227.elettra.trieste.it> has joined #yocto07:34
*** alessioigor <alessioigor!~alessioig@out-207-227.elettra.trieste.it> has quit IRC07:34
*** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has joined #yocto07:37
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:41
*** sagner <sagner!~ags@37.17.234.113> has quit IRC07:48
ThomasD13Is it possible to provide kernel cfg-files, for "virtual/kernel" ? I want to enable specific kernel options, regardless of which particular kernel I use07:50
ThomasD13Regardless for example if I use raspberrypi-kernel or linux-vanilla07:51
mcfriskThomasD13: in theory yes, if the kernel recipes are similar to yocto defaults. Though in practice with various BSP layers for different SoC's I've never seen this actually working and it's easier to just maintain a target specific kernel config.07:55
ThomasD13thank you mcfrisk07:55
*** sagner <sagner!~ags@31-10-206-124.static.upc.ch> has joined #yocto08:01
LetoThe2ndwe have a multiconfig where mc1 refers to an aritifact of mc0. whats the correct/best way to invalidate sstate once the artifact is rebuilt?08:04
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC08:08
ThomasD13I've noticed that the layer.conf (created by "bitbake layer tools") looks like this: BBFILES += "${LAYERDIR}/recipes/*/*.bb \08:08
ThomasD13            ${LAYERDIR}/appends/*.bbappend"08:08
ThomasD13Is that a common way to specify .bbappend in a different path of .bb files?08:09
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has joined #yocto08:10
ThomasD13Is there a best practise for .bbappend-files, like to put the layer-directory outside of poky?08:11
LetoThe2ndThomasD13: thats always a best practise08:11
ThomasD13@LetoThe2nd, to summarize all .bbappend-files in top directory "appends"?08:12
LetoThe2ndThomasD13: nope, no have everything outside of upstream poky08:12
*** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto08:13
*** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has quit IRC08:13
khemrburton: with latest master-next I am seeing sstate issue with go-native see http://jenkins.nas-admin.org/view/OE/job/oe_world_workspace-compare-signatures/872/console08:15
khemany ideas ?08:15
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto08:18
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC08:28
yoctiNew news from stackoverflow: Docker image format <https://stackoverflow.com/questions/25583038/docker-image-format>08:33
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto08:33
*** rubdos <rubdos!~rubdos@77.109.116.248> has joined #yocto08:38
LetoThe2ndjust faling to see the probably obvious. how to restrict an append to a specific DISTRO?08:52
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto08:55
*** 07IAC7G4O <07IAC7G4O!~cquast@90.85.130.193> has joined #yocto09:01
LetoThe2nd(other than doing the _distro dance for all things inside it, of course)09:02
*** yann|work <yann|work!~yann@85.118.38.73> has joined #yocto09:10
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto09:12
rburtonwhoops aehs29 back in 2015 accidentally turned off python bytecode optimisation09:17
rburtonand nobody noticed09:17
* LetoThe2nd wouldn't notice for many more years, cause no using python :)09:18
rburtoni cleaned up some patches and suddenly the packages all got bigger as .pyo files were being generated09:18
*** goliath <goliath!~goliath@nat004-WLTU1.uibk.ac.at> has joined #yocto09:19
LetoThe2ndRP: do we already have some examples/best practises concerning a mc referring to a rootfs baked in another mc? we're starting to get our heads around it, but trip over one strangeness after the other.09:20
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:23
*** mckoan|away is now known as mckoan09:24
*** florian_kc is now known as florian09:26
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC09:29
qschulzbluelightning: thanks for taking the patch (meta-qt4). I should really take a few days off... Not a mistake I usually do, sorry.09:32
RPLetoThe2nd: I think aehs29's layer had an example?09:38
ThomasD13I get crazy here :D - What could be possibly gone wrong when a kernel option is not set in my final kernel, but the configuration fragment (.cfg) shows up in the temp/kernel/... - directory?09:43
LetoThe2ndRP: kay, let me look it up09:45
LetoThe2ndRP: you mean meta-freertos?09:47
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-gruasfyxjskvvoxy> has joined #yocto09:50
*** wooosaiiii <wooosaiiii!~prix@89-212-21-243.static.t-2.net> has quit IRC10:00
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC10:03
*** lfa <lfa!~lfa@217.19.35.51> has joined #yocto10:14
qschulzThomasD13: I'm not using KConfig fragment so need to be checked but.. have you checked your KERNEL_FEATURES? https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-KERNEL_FEATURES10:15
ThomasD13qschulz, thanks I will look into that. Said that, some other fragments find their way into final .config. I just don't see the difference between working and not working fragments10:19
ThomasD13I'm currently trying to debug the do.run_kernel_configme. Which calls a script that works on the fragment files10:19
*** frosteyes <frosteyes!~frosteyes@185.53.130.211> has quit IRC10:19
ThomasD13There should be somewhere a merge_config_build.log file, but I cannot find it :(10:20
ThomasD13ahhh yeah! I found it!10:25
ThomasD13https://pastebin.com/sJrku6S310:27
*** bjobjo <bjobjo!~bjobjo@2a01:79d:3e81:5208::9e6> has joined #yocto10:28
ThomasD13"Value requested for CONFIG_STRICT_DEVMEM not in final .config" Okay, thats my problem. Why isn't this printed somewhere as warning during the build process?10:28
qschulzThomasD13: there is a fatal error only when merge_config.sh is returning != 010:32
qschulzso merge_config.sh has "successfully" completed10:32
qschulzbut you know, IMO, good contribution to kernel-yocto.bbclass10:33
yoctiNew news from stackoverflow: How to get the ARM tool chain with poky? <https://stackoverflow.com/questions/59048325/how-to-get-the-arm-tool-chain-with-poky>10:33
*** wooosaiiii <wooosaiiii!~prix@89-212-21-243.static.t-2.net> has joined #yocto10:33
*** frosteyes <frosteyes!~frosteyes@185.53.130.211> has joined #yocto10:34
ThomasD13qschulz, okay. I get the feeling that cfg fragments only get applied if the specific option already "exist" within the defconfig. Is that correct?10:34
qschulzThomasD13: I don't know, you'10:35
qschulzd have to have a look at merge_config.sh script :)10:35
cengiz_iohello. I know I'm missing something simple but can you help me overcome this library recipe QA errors? https://gist.github.com/cengizIO/f0e2cf2c2e8f84aab63719a2e76aabc610:41
cengiz_iodev-elf and dev-deps10:42
cengiz_ioread the docs but couldn't understand what I'm doing wrong..10:42
cengiz_iorburton would probably beat me10:42
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has quit IRC10:44
*** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has joined #yocto10:44
qschulzcengiz_io: the so library you have in dev should be a symlink to the .so.x.y.z lib is my understanding of your warning10:53
qschulzcengiz_io: if you have a versioned library, just use a symlink instead of copying the versioned library and strip the version out of its filename.10:55
qschulzcengiz_io: or if it isn't a versioned library, add the .so lib to FILES_${PN} but I **think** it'll trigger another warning10:55
cengiz_ioqschulz all I do is `make` the library and it produces `libfreeimage-3.18.so`10:55
qschulzhttps://github.com/webOS-ports/meta-webos-ports/blob/master/meta-luneos/recipes-support/freeimage/freeimage_3.17.0.bb10:56
qschulzcengiz_io: ^ that's a recipe for your SW which is linked from https://layers.openembedded.org/layerindex/recipe/51447/10:57
qschulzso maybe you can take some inspiration out of it10:57
*** goliath <goliath!~goliath@nat004-WLTU1.uibk.ac.at> has quit IRC10:57
cengiz_ioqschulz didn't know that. thanks.10:59
cengiz_ioit's so confusing. I assumed that bitbake is already adding header files to -dev package and .so files to regular recipe11:00
LetoThe2ndcengiz_io: but this is based on path, and if the install stage of the package is b0rk3d, then bitbake gets confused.11:00
LetoThe2ndcengiz_io: and the do_configure + do_install stage of the recipe that qschulz linked pretty much suggest that the original install stage makes bad assumptions.11:01
cengiz_ioLetoThe2nd it does... installing with root permissions etc11:01
qschulzcengiz_io: it actually isn't. /usr/lib/lib*.so.* are in regular package, /usr/lib/lib*.so are in -dev package11:02
qschulzbecause sensible people do not provide a .so but a .so.x.y.z so it's easy to know which version is being used at one point. And then if some SW linking against does not care much about the version of the lib or only for some major version, then they provide/use symlinks to versioned libraries11:04
cengiz_ioqschulz LetoThe2nd: libfreeimage-3.18.0.so is the only artifact that Makefile produces11:05
cengiz_iowithout modifying with recipe11:06
cengiz_io(I've disabled static lib)11:06
cengiz_iomaybe it's the naming?11:06
qschulzcengiz_io: I know you're not responsible of this, I'm just saying what people usually expect from libraries and why what I'm explaining is the default in Yocto11:06
cengiz_ioqschulz ofcourse. I'm just trying to understand what's wrong and what it should be11:07
qschulzat worst libfreeimage-3.18.0.so.x.y.z11:07
qschulzbut from the naming, it might actually just be a malformed lib filename. MAYBE, it could be libfreeimage.so.3.18.011:08
qschulzwhich makes the most sense because I'm not sure SW linking against this libraries are actually saying they want to link against libfreeimage-3.18.0.so but more libfreeimage.so (maybe with version number appended)11:09
qschulzcengiz_io: https://github.com/webOS-ports/FreeImage/blob/master/Makefile.gnu#L3811:09
qschulzthis most likely should be lib$(TARGET).so.$(VER_MAJOR).$(VER_MINOR)11:10
cengiz_ioyep.11:10
cengiz_iothat's makes more sense11:10
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has quit IRC11:13
*** Dracos-Carazza_ is now known as Dracos-Carazza11:14
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC11:21
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto11:22
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has joined #yocto11:24
*** thedarrens <thedarrens!~thedarren@unstableheros98.plus.com> has joined #yocto11:27
thedarrensGreetings folks.11:28
thedarrensThis brings back some memories. I have not used irc since the late 80s early 90s took me a bit to remember everything.11:29
thedarrensPost this in Poky as well. Just wante to make sure everyone understand where I come from :) Just a little bit of backstory per say. I am a learning disabled 52yr old but I love to learn new things. So I was told about Yocto to do with a project myself and my partner are wanting to do.11:33
thedarrensbut here is the error I am getting and nope I can not program to save my life YET. :) but going to start to learn.11:33
thedarrensERROR: Task (virtual:native:/home/thedarrens/Gubbins/Yocto/FHOS/poky/meta/recipes-devtools/bison/bison_3.0.4.bb:do_compile) failed with exit code '1'11:34
thedarrens../bison-3.0.4/lib/fseterr.c:77:3: error: #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib."11:35
thedarrens|    77 |  #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib."11:35
*** xtron <xtron!~xtron@110.93.212.98> has joined #yocto11:43
rburtoncengiz_io: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries11:43
*** berton <berton!~berton@189.103.49.163> has joined #yocto11:43
xtroncouldn't found recipe dependency list with bitbake -g recipe, any idea why?11:46
*** berton <berton!~berton@189.103.49.163> has quit IRC11:46
rburtonthedarrens: that looks like an error from an older release of poky on a modern system which broke bison.11:48
*** berton <berton!~berton@189.103.49.163> has joined #yocto11:48
rburtonthedarrens: ideally, switch to the latest release of poky (3.0/zeus)11:48
thedarrensok will do that I did do a git, sorry still learning will try it again thank ruburton11:48
rburtoni thought we'd fixed up the stable releases by now, so i suspect you're using an old release - on purpose or accident11:50
rburtoni mean, even if you wanted to stick with 2.7 or 2.6, the latest point release of those had that fixed.11:50
thedarrensmust be by accident.  I did  this to get it11:51
thedarrensgit clone -b sumo git://git.yoctoproject.org/poky.git11:51
rburtonhm maybe we didn't fix sumo.11:51
thedarrenswell it is a learning expeiance so off to do it again11:51
rburtonanyway thats old.  if you're not tied to sumo for any particular reason, switch to zeus11:51
thedarrensnot at all. As I said on was just told to learn yocto from a old friend that knows about my learning disabilies and hell here I go.11:53
thedarrensTHanks again Rburton11:53
LetoThe2ndthedarrens: you can find a lot of introductory explanations at https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj11:57
thedarrenssweet Thank you Leto.11:58
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has quit IRC11:58
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC11:59
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto12:03
*** sagner <sagner!~ags@31-10-206-124.static.upc.ch> has quit IRC12:06
*** sagner <sagner!~ags@31-10-206-124.static.upc.ch> has joined #yocto12:08
thedarrensWell, that seems to be working much better. Thank you again.12:25
cengiz_iothx rburton12:27
millonimaybe a silly question but why does poky core-image-minimal run dbus-daemon?12:59
millonisorry why does it *not* run dbus-daemon?12:59
LetoThe2ndprobably because there is no dbus installed by default, unless you tinkered with poky13:00
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC13:01
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has joined #yocto13:02
yoctiNew news from stackoverflow: Bitbake: How to only fetch the sources? <https://stackoverflow.com/questions/54078174/bitbake-how-to-only-fetch-the-sources>13:03
LetoThe2ndmilloni: if you add systemd as explained in the documentation (and shown in the live coding sessions) you get dbus basically for free ;-P13:03
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has quit IRC13:04
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto13:05
thedarrensWatching that right now actually Thank you again LetoThe2nd this will advance the disability project we want to try to do13:05
milloniLetoThe2nd: i know, but that's the thing - even if you have systemd installed - it still does *not* have dbus-daemon13:05
milloniit does have dbus (the library) and it does use dbus13:06
millonibut not dbus-daemon13:06
millonii just saw agl have a bbappend for dbus that adds a systemd service for dbus-daemon and i was like "oh really?"13:07
LetoThe2ndthedarrens: have fun. if you have questions concerning something in the videos, just ask around here. i'm not always around of course, but we'll try to answer ASAP :)13:10
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto13:11
thedarrensNo, problem I will do that. lol, I fell like I am 20 again back in the late 80s all I need now is a bbs and I am sorted.13:11
*** frsc <frsc!~frsc@2003:a:a75:a900:adf8:707f:f819:baef> has joined #yocto13:22
*** Chrusel <Chrusel!c1669b04@193.102.155.4> has joined #yocto13:25
millonimy bad, it does install dbus-daemon if on a configuration with systemd13:36
millonipresumably the agl bbappend is redundant13:36
*** ongy <ongy!~ongyerth@unaffiliated/ongy> has joined #yocto13:52
ongyWhen I try to to use musl as dependency, it gets skipped because glibc is set as provider for virtual/libc. But I only need musl to static-link inside our initram, it should never end in the rootfs (nor initram for what it's worth). Is there a trick to pull it in regardless, or will I have to pre-compile the binaries for the initram? (I think that's what poky does?)13:53
ongyThe alternative I though about was to create my own recipe (musl-internal) and have that provide the build-dependencies and avoid the musl that's in poky, which hopefully fixes my usecase but isn't too nice either13:59
xtronpackage-mangement with opkg is updating or showing list-installed14:01
xtronnot*14:01
xtronpackage_feed_uris and arch variables are defined but not reflecting in opkg configuration14:02
xtronopkg list-installed is empty14:03
xtronanyone else using package-management saw this behavior??14:04
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto14:07
*** xtron <xtron!~xtron@110.93.212.98> has quit IRC14:09
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC14:22
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto14:26
thedarrens@LetoThe2nd, would there happen to also been some documentation on, and I am not sure how to phrase this, adding a desktop environment etc Or is that also covered in the videos, Just about at the end of number 114:28
*** crawler <crawler!~crawler@193.135.254.19> has joined #yocto14:29
crawlerHi guys, i have a strange problem regarding yocto and initramfs.. I managed to compile and build initramfs, in the tmp/deploy/images i get file like zImage-initramfs-4.14.xxx.bin, but also i have file zImage--4.14.xxx.bin - which means i have kernel and kernel with initramfs.. final (wks) image for sdcard have only zImage, without initramfs.. i do not use wks boot-partition plugin... question, how do i replace zImage with zImage-initramfs in root14:36
crawlerfilesystem /boot?14:36
crawlerdocumentation statets that if i put in local.conf INITRAMFS_IMAGE_BUNDLE = "1" it should do the trick14:37
*** sagner <sagner!~ags@31-10-206-124.static.upc.ch> has quit IRC14:38
crawlerbut no matter what i tried (and i tried few things found on internet) i cant get initramfs image in final image14:38
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC14:40
crawlerim lost..14:40
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto14:41
rburtonRP: any idea who to blame for | make[1]: /home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/gcc-crosssdk-aarch64-pokysdk-linux/9.2.0-r0/gcc-9.2.0/build.x86_64-linux.aarch64-pokysdk-linux/./gcc/xgcc: Command not found14:42
*** sagner <sagner!~ags@31-10-206-124.static.upc.ch> has joined #yocto14:45
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:00
* armpit blame the old guy in CA15:03
armpitrburton, was that selftest?15:04
armpitin master-next ?15:05
armpithttps://git.openembedded.org/openembedded-core/commit/?h=master-next&id=17ea7a4155c1dafde769b18b0372c1c7372d0dc515:05
armpitmaybe ?15:05
mckoanI have a question about Building Software from an External Source15:09
mckoanfollowing this https://www.yoctoproject.org/docs/3.0/dev-manual/dev-manual.html#building-software-from-an-external-source15:09
mckoanlooks like you simply nee to include in a recipe inherit externalsrc EXTERNALSRC = "/path/to/sources"15:10
mckoanbut testing that in a recipe it fails15:10
mckoanactually the build works only if you also set EXTERNALSRC_BUILD = "/some/path15:11
GeneralStupidHi, is there a more detailes documentation for "do_image"?15:11
GeneralStupidor / and "do_deploy"15:11
mckoanbut externalsrc.bbclass says that         if externalsrcbuild:15:11
mckoan            d.setVar('B', externalsrcbuild)15:11
mckoan        else:15:11
mckoan            d.setVar('B', '${WORKDIR}/${BPN}-${PV}/')15:11
mckoanthe latter is ignored completely15:12
mckoanam I misunderstanding something?15:12
qschulzGeneralStupid: https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#normal-recipe-build-tasks15:15
qschulzmckoan: if EXTERNALSRC_BUILD is not set, the build directory is actually WORKDIR/$BPN-$PV which is the default for recipes. If it is set, to whatever you've set it to15:16
qschulz"By default, externalsrc.bbclass builds the source code in a directory separate from the external source directory as specified by EXTERNALSRC. If you need to have the source built in the same directory in which it resides, or some other nominated directory, you can set EXTERNALSRC_BUILD to point to that directory: "15:17
qschulzhttps://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#building-software-from-an-external-source15:17
*** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has quit IRC15:18
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto15:20
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto15:24
LetoThe2ndthedarrens: nope, there is nothing on desktop environments. and i actually don't plan to do so, at least not in the video series as it is not really a common usecase15:25
mckoanqschulz: that's the problem. If EXTERNALSRC_BUILD is not set WORKDIR/$BPN-$PV is empty15:28
RPrburton: no, not without more context15:29
*** frsc <frsc!~frsc@2003:a:a75:a900:adf8:707f:f819:baef> has quit IRC15:32
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC15:34
qschulzmckoan: your makefile/cmake whatever does not use B correctly? (overriden flags or whatever is passed by yocto to give where to do all the builds) throwing ideas :)15:34
qschulzmckoan: kind of the behavior of autotools-brokensep for externalsrc?15:35
tgamblinrburton: armpit: I've been looking at https://bugzilla.yoctoproject.org/show_bug.cgi?id=13632 (and 13602) but haven't been able to recreate the fail even under high system load. Any ideas on how to recreate the failure?15:35
yoctiBug 13632: normal, Medium+, 3.1 M1, trevor.gamblin, NEW , logrotate.LogrotateTest.test_2_logrotate selftest failure in core-image-full-cmdline15:35
armpittgamblin, sorry no ideas15:39
armpitRP, any reason why the last few patches for zeus merge request got dropped ?15:40
mckoanqschulz: that may be the only reason, thx15:43
rburtonarmpit: buildtools, my next branch15:43
armpitrburton, what ?15:45
RParmpit: no reason, I think I just messed up. There were whitespace issues with patches and merges. Can you rebase the branch and I'll see what is left?15:45
armpitRP, will do.15:46
khemrburton: some new build failures due to python stuff in master-next see https://errors.yoctoproject.org/Errors/Build/93168/15:47
*** vineela <vineela!~vtummala@134.134.137.73> has joined #yocto15:47
RParmpit: also updated -helper as you mentioned15:47
armpitcool15:48
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto15:49
rburtonoh rp added the no-py2 bits15:50
rburtonbold15:50
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto15:50
rburtonglmark and jack are waf being dumb15:51
RPrburton: not many failures and the things that did fail aren't clearly related15:51
rburtonkhem: easy fix is to add python to hosttools in meta-oe's layer.conf :)15:51
armpitRP, rebased.15:53
RParmpit: which branch?15:55
armpithttps://git.openembedded.org/openembedded-core-contrib/log/?h=stable/zeus-next15:56
armpitYPTM - armin in on15:56
dl9pfYPTM - Jan-Simon is on15:56
khemrburton: I would rather like patches to fix the problems15:56
tgamblinYPTM - Trevor is on15:59
RParmpit: that branch was updated 3 daya ago?15:59
*** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has joined #yocto15:59
* RP is missing something15:59
moto-timoYPTM - moto-timo joined16:00
armpitcorrect. I pushed my -nut version which is what was tested16:00
smurrayYPTM - Scott Murray joined16:00
RParmpit: I asked if you could rebase it, you said yes?16:00
armpitgit said no change... fine.. I will make it change16:01
RParmpit: hmm, it did? :/16:02
rburtonkhem: someone might need to update jack to a recent release first16:02
*** sagner <sagner!~ags@31-10-206-124.static.upc.ch> has quit IRC16:03
denixYPTM - Denys is on16:03
khemrburton: usually updates will solve lot of such issues, since other distros are getting py2 free as well16:04
khemYPTM - Khem is on16:08
thedarrens@LetoThe2nd, ok, thanks.16:10
LetoThe2ndthedarrens: what is your actual usecase?16:12
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC16:13
*** vineela <vineela!~vtummala@134.134.137.73> has quit IRC16:14
*** sagner <sagner!~ags@37.17.234.113> has joined #yocto16:16
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:19
*** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC16:20
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC16:21
moto-timomk-meta-python2.sh script: https://gist.github.com/moto-timo/ab70ab96ddbaf5fd1226bd21dbbfec9b16:22
*** 07IAC7G4O <07IAC7G4O!~cquast@90.85.130.193> has quit IRC16:22
moto-timothis requires git-filter-repo https://github.com/newren/git-filter-repo16:23
kergothmoto-timo: nice. i'd never seen filter-repo, that looks handy16:26
moto-timokergoth: this is VERY fast compared to filter-branch16:31
kergothi think one of the biggest annoyances i had doing repo splits like this was dealing with renames intelligently when the files moved in and out of the boundaries of the subdir i'm filtering out. bit of a mess16:31
moto-timokergoth: filter-repo is quite capable, but the examples are a little light on content so far...16:33
rburtonmoto-timo: personally i'd just copy/paste and ignore the history :)16:34
*** frsc <frsc!~frsc@2003:a:a75:a900:adf8:707f:f819:baef> has joined #yocto16:35
kergothi like the idea of keeping it if it's not too troublesome, being able to still git-blame and whatnot is helpful16:36
kergothbut yeah, depends on the difficulty vs time constraints really..16:37
moto-timothe history bit is done. the rest is cleanup that had to happen even with copy-paste16:37
khemmoto-timo: are you using git filter-branch ?16:41
moto-timokhem: I replaced it with git-filter-repo. much more capable and faster16:42
khemi see cool16:42
moto-timokhem: I haven't quite gotten the handle of using it as a library, but command line (as in my gist) is working pretty well. The --replace-text option is not quite working properly with regex...16:43
moto-timoso I stopped using it and used the --blob-callback instead16:44
* armpit why did I get a Disco reference from moto-timo email?? python2 staying-alive16:45
* moto-timo laughs with armpit16:46
*** Chrusel <Chrusel!c1669b04@193.102.155.4> has quit IRC16:46
moto-timoit needs a logo with the disco floor lights...16:46
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC16:46
khemubuntu codename I guess16:47
armpitand the platform shoes with yocto printed on them16:47
khemeither have codenames or release names but eh16:47
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto16:48
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC16:48
RPJPEW: I think what I wasn't clear about - sstate will restore any matching hashes and it ignores dependencies unless they're "hard" deps. "hard" deps are only pseudo-native and useradd stuff17:00
RPJPEW: so when the hash for an already installed artefact changes, all bets are off17:01
*** abhiarora44 <abhiarora44!uid396576@gateway/web/irccloud.com/x-irqzpuqqsgbaghho> has joined #yocto17:03
yoctiNew news from stackoverflow: How to compile a basic c file in yocto <https://stackoverflow.com/questions/37705995/how-to-compile-a-basic-c-file-in-yocto>17:04
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC17:15
*** thedarrens <thedarrens!~thedarren@unstableheros98.plus.com> has quit IRC17:15
*** vineela <vineela!~vtummala@134.134.137.73> has joined #yocto17:16
*** yann|work <yann|work!~yann@85.118.38.73> has quit IRC17:29
*** rubdos <rubdos!~rubdos@77.109.116.248> has quit IRC17:31
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC17:34
aehs29rburton: :O17:54
rburtonaehs29: copy-paste failures that nobody noticed for years! https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/next&id=560f339443a1cd57a1d8a9f9f0cc8aacbb627fef17:54
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC17:56
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:57
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto18:00
JPEWRP: I had a thought: do we (or could we) know that gdb-cross is being rebuilt because the sstate object is missing?18:01
RPJPEW: yes, but we don't know why that could be18:02
RPJPEW: the clue is when we rebuild it and an artefact which matched no longer does18:03
*** mckoan is now known as mckoan|away18:04
JPEWRP: Right, I guess I wonder if we need to report a hash to the server in that case. We've already asked the server what the unihash for that taskhash *should* be, reporting it to the server and giving it the option to change it based on outhash seems unnecessary (in that specific case)18:05
JPEW*if* we can say this task is executing because it is missing sstate and is a dependency for another setscene task18:06
JPEWEffectively, it means "create the sstate object with this unihash, we don't really care too much if it's contents match because we aren't going to rebuild downstream anyway"18:07
RPJPEW: not sure that helps us18:08
* kergoth works on fixing meta-external-toolchain to handle an oe/yocto sdk18:09
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto18:14
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC18:19
rburtonkhem: jack and glmark fixes posted18:26
*** armpit <armpit!~armpit@2601:202:4180:a5c0:4070:35fc:4101:33f5> has quit IRC18:26
khemrburton: cool thank you18:27
khemrburton: meta-qt5 will need some py3 love http://errors.yoctoproject.org/Errors/Build/93179/18:27
rburtonsomeone else can deal with that18:27
khemrburton: there is just universal conciousness, all is one, there is no one else18:32
khemrburton: hence you have to fix it18:32
khemrburton: I only see glmark2 fix on ml18:39
*** chandana73 <chandana73!~ckalluri@149.199.62.130> has joined #yocto18:42
*** comptroller <comptroller!~comptroll@47-213-230-143.paolcmtc01.res.dyn.suddenlink.net> has quit IRC18:43
*** xtron <xtron!~xtron@103.26.85.188> has joined #yocto18:53
*** chandana73 <chandana73!~ckalluri@149.199.62.130> has quit IRC18:55
*** chandana73 <chandana73!~ckalluri@149.199.62.130> has joined #yocto18:55
*** berton_ <berton_!~berton@189.103.49.163> has joined #yocto19:07
*** comptroller <comptroller!~comptroll@47-213-230-143.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto19:09
*** jubalh <jubalh!jubalh@unaffiliated/jubalh> has joined #yocto19:10
jubalhhi19:10
*** berton <berton!~berton@189.103.49.163> has quit IRC19:10
*** rubdos <rubdos!~rubdos@77.109.116.248> has joined #yocto19:13
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-gruasfyxjskvvoxy> has quit IRC19:20
*** comptroller <comptroller!~comptroll@47-213-230-143.paolcmtc01.res.dyn.suddenlink.net> has quit IRC19:21
*** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has joined #yocto19:32
*** guerinoni <guerinoni!~guerinoni@host238-179-dynamic.51-79-r.retail.telecomitalia.it> has joined #yocto19:34
*** florian_kc is now known as florian19:35
*** rubdos <rubdos!~rubdos@77.109.116.248> has quit IRC19:36
*** guerinoni <guerinoni!~guerinoni@host238-179-dynamic.51-79-r.retail.telecomitalia.it> has quit IRC19:37
*** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto19:37
*** comptroller <comptroller!~comptroll@47-213-230-143.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto19:40
*** xtron <xtron!~xtron@103.26.85.188> has quit IRC19:41
*** guerinoni <guerinoni!~guerinoni@host238-179-dynamic.51-79-r.retail.telecomitalia.it> has joined #yocto19:44
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto19:50
*** rubdos <rubdos!~rubdos@77.109.116.248> has joined #yocto19:50
khemrburton RP hg fetcher is ending in fetch failures seems py2 related see http://errors.yoctoproject.org/Errors/Details/283512/19:55
*** guerinoni <guerinoni!~guerinoni@host238-179-dynamic.51-79-r.retail.telecomitalia.it> has quit IRC19:56
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC19:58
khemmercurial recipe needs py3 migration too hmm ok19:59
*** leitao <leitao!~leitao@2620:10d:c092:180::1:c778> has joined #yocto20:01
smurraykhem: when I did a test with py2 removed a couple of months ago, mercurial seemed like it'd need some work.  jack was another one, it's a dependency for a few other things so might be more problematic to blacklist20:04
smurraykhem: heh, I see rburton has jack fixed already20:06
*** armpit <armpit!~armpit@45.19.219.178> has joined #yocto20:36
*** berton_ <berton_!~berton@189.103.49.163> has quit IRC20:39
*** leitao <leitao!~leitao@2620:10d:c092:180::1:c778> has quit IRC20:41
*** abhiarora44 <abhiarora44!uid396576@gateway/web/irccloud.com/x-irqzpuqqsgbaghho> has quit IRC20:43
*** rubdos <rubdos!~rubdos@77.109.116.248> has quit IRC20:49
khemyeah mostly I have sent few fixes20:52
khemmercurial 5.2 has py3 support20:52
khemso lets see how far20:52
rburtonsomeone else can deal with hg :)20:52
khemyeah I have it fixed dont worry20:53
rburtonkhem: i've a better jack fix that i somehow didn't send21:03
rburtonposted21:03
rburtonalso replicated your htop one :)21:03
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto21:06
*** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-pkzqeaeoukxeewim> has quit IRC21:06
rburtonRP: next is one build away from green.  weird buildtools failure disappeared on rebuild...21:07
*** BobPungartnik <BobPungartnik!~BobPungar@177.206.114.105.dynamic.adsl.gvt.net.br> has joined #yocto21:20
*** armpit <armpit!~armpit@45.19.219.178> has quit IRC21:27
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto21:28
RPrburton: yours or mine?21:30
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has quit IRC21:42
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has joined #yocto21:43
*** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-rfhwgjyxnpewodtr> has joined #yocto21:45
rewittRP: I'm getting the tar sanity check failure from 2c7624c17e43f9215cf7dcebf7258d28711bc3ce (https://travis-ci.org/crops/yocto-dockerfiles/jobs/617421188). Are you using the buildtools-tarball to get around that on the autobuilder?21:56
rewittRP: Looks like it happens on Centos7 and Ubuntu 14.0421:57
RPrewitt: yes, we are using buildtools-tarball on centos7 and debian821:57
RPrewitt: 1404 is out of support now so we don't have one of those21:57
*** pohly <pohly!~pohly@p54BD5B80.dip0.t-ipconnect.de> has quit IRC21:58
rewittRP: Ok thanks, I just wanted to make sure I wasn't missing some distro package update.21:59
rewittI should probably turn of 1404 as well, I think last time I checked I was looking at EOL only.22:00
rburtonRP: mine22:00
*** BobPungartnik <BobPungartnik!~BobPungar@177.206.114.105.dynamic.adsl.gvt.net.br> has quit IRC22:00
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC22:02
RPrewitt: given centos7 is getting old, this seemed like the best way forward for the project and reproducibility...22:02
rewittRP: I have no problems with it, just wanted to make sure I wasn't screwing something up.22:03
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC22:05
RPrewitt: not at all. Good to see you btw! :)22:22
rewittRP: Yeah I'm still alive :)22:31
rewittRP: I just lurk in here until I need something ;)22:32
*** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has quit IRC22:38
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto22:45
rburtonRP: drop  'python: clean up command overriding' from next please23:07
RPrburton: gone23:09
RPrburton: does that cause fails on the AB?23:09
rburtonno, just bad packages23:09
RPrburton: ok23:09
rburtongot a fixed series, just need to write nice commit messages23:09
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC23:23
*** anujm <anujm!~anujm@134.134.139.76> has joined #yocto23:26
*** chandana73 <chandana73!~ckalluri@149.199.62.130> has quit IRC23:59

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!