Friday, 2019-02-08

*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC00:02
*** marka <marka!~masselst@> has quit IRC00:04
*** marka <marka!~marka@> has joined #yocto00:05
*** TundraMan <TundraMan!~masselst@> has joined #yocto00:05
*** TundraMan <TundraMan!~masselst@> has quit IRC00:14
*** TundraMan <TundraMan!~masselst@> has joined #yocto00:17
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto00:21
*** marka <marka!~marka@> has quit IRC00:24
*** marka <marka!~marka@> has joined #yocto00:25
*** marka <marka!~marka@> has quit IRC00:28
*** sjolley <sjolley!> has joined #yocto00:33
*** rburton_ <rburton_!> has quit IRC00:41
*** dev1990 <dev1990!> has quit IRC00:48
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto00:51
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC01:06
*** marka <marka!~marka@> has joined #yocto01:22
*** chandana73 <chandana73!~ckalluri@> has quit IRC01:35
*** chandana73 <chandana73!~ckalluri@> has joined #yocto01:36
*** sjolley <sjolley!> has quit IRC01:52
*** nighty- <nighty-!> has joined #yocto01:52
*** learningc <learningc!> has joined #yocto02:06
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC02:16
*** learningc <learningc!> has quit IRC02:20
*** learningc <learningc!> has joined #yocto02:20
chandana73RP: i sent out a patch based on the discussion from morning regarding devtool reset -r option02:42
*** learningc <learningc!> has quit IRC03:19
*** learningc <learningc!> has joined #yocto03:20
*** chandana73 <chandana73!~ckalluri@> has quit IRC03:40
*** pbb <pbb!> has quit IRC03:42
*** pbb <pbb!> has joined #yocto03:42
*** sjolley <sjolley!> has joined #yocto03:49
*** robbawebba <robbawebba!~rob@> has joined #yocto04:19
*** learningc <learningc!> has quit IRC04:20
*** learningc <learningc!> has joined #yocto04:20
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:36
*** behanw <behanw!uid110099@gateway/web/> has joined #yocto05:01
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC05:07
*** otavio <otavio!~otavio@> has joined #yocto05:09
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto05:09
*** learningc <learningc!> has quit IRC05:20
*** learningc <learningc!> has joined #yocto05:20
*** kroon <kroon!> has quit IRC05:30
*** hamis <hamis!~irfan@> has joined #yocto06:04
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto06:15
*** learningc <learningc!> has quit IRC06:20
*** learningc <learningc!> has joined #yocto06:20
*** AndersD <AndersD!~AndersD@> has joined #yocto06:26
*** sno <sno!> has quit IRC06:28
*** comptroller <comptroller!> has quit IRC06:32
*** agust <agust!> has joined #yocto06:35
*** jobroe <jobroe!~manjaro-u@> has joined #yocto06:35
*** AndersD <AndersD!~AndersD@> has quit IRC06:40
*** AndersD <AndersD!> has joined #yocto06:42
*** sjolley <sjolley!> has quit IRC06:43
*** sno <sno!> has joined #yocto06:52
*** evotion <evotion!d918c92f@gateway/web/freenode/ip.> has joined #yocto06:57
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto07:01
*** TobSnyder <TobSnyder!> has joined #yocto07:16
*** tprrt <tprrt!~tprrt@> has joined #yocto07:16
*** volestorm <volestorm!~volestorm@2400:8902::f03c:91ff:fe7f:f462> has quit IRC07:19
*** cvasilak <cvasilak!> has joined #yocto07:20
*** learningc <learningc!> has quit IRC07:20
*** learningc <learningc!> has joined #yocto07:21
*** AndersD_ <AndersD_!> has joined #yocto07:30
*** AndersD <AndersD!> has quit IRC07:33
*** jmiehe <jmiehe!> has joined #yocto07:34
*** tasslehoff_ <tasslehoff_!~Tasslehof@> has joined #yocto07:39
*** behanw <behanw!uid110099@gateway/web/> has quit IRC07:41
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC07:55
*** lusus <lusus!~lusus@> has joined #yocto08:08
*** fl0v0 <fl0v0!> has joined #yocto08:08
*** varjag <varjag!> has joined #yocto08:11
*** volestorm <volestorm!> has joined #yocto08:14
*** learningc <learningc!> has quit IRC08:20
*** learningc <learningc!> has joined #yocto08:21
*** JaMa <JaMa!~martin@> has quit IRC08:22
*** Bunio_FH <Bunio_FH!> has joined #yocto08:30
*** agust <agust!> has quit IRC08:30
*** agust <agust!> has joined #yocto08:30
*** edgar444 <edgar444!uid214381@gateway/web/> has joined #yocto08:37
*** Bunio_FH <Bunio_FH!> has quit IRC08:39
*** mckoan|away is now known as mckoan08:39
*** sb79a <sb79a!> has joined #yocto08:40
*** Bunio_FH <Bunio_FH!> has joined #yocto08:43
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:00
*** flying_sausages <flying_sausages!> has quit IRC09:01
*** flying_sausages <flying_sausages!> has joined #yocto09:02
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:04
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto09:10
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto09:12
*** sno <sno!> has quit IRC09:14
*** rburton <rburton!> has joined #yocto09:14
*** learningc <learningc!> has quit IRC09:20
*** learningc <learningc!> has joined #yocto09:21
RPkanavin: any objection if I squash a few of your python patches together and move it back to python instead of python-sanity ?09:22
*** bluelightning_ is now known as bluelightning09:24
*** sno <sno!> has joined #yocto09:26
evotionHi, I have a problem regarding sstate and rebuilds of images. When I change my recipe PV, which currently just does do_install and do_deploy a ASCII file, the ipk and deploy step is done correctly and all files are updated. But the image including this recipe does not rebuild and uses the old version. is an example how this was done. Does someone have an idea, what to do, to make the image update itself?09:31
*** jofr <jofr!~jofr@> has quit IRC09:44
*** jofr <jofr!~jofr@> has joined #yocto09:44
RPevotion: how is the image depending on this recipe?09:50
RPevotion: also, how is PV in the recipe set?09:51
*** rburton <rburton!> has quit IRC09:53
*** rburton <rburton!> has joined #yocto09:53
evotionRP: PV is set via the recipe file name. The package is in PACKAGE_INSTALL of the image.09:55
*** rewitt1 <rewitt1!rewitt@nat/intel/x-khtocrbrryqsersx> has joined #yocto09:55
rburtonso all the deploy stuff is redundant?09:55
*** stephano2 <stephano2!~stephano@> has joined #yocto09:55
*** sgw <sgw!~sgw@> has quit IRC09:56
*** rewitt <rewitt!rewitt@nat/intel/x-myeavinruwakgvts> has quit IRC09:57
*** stephano <stephano!~stephano@> has quit IRC09:57
*** sgw <sgw!~sgw@> has joined #yocto09:58
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC10:02
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto10:02
RPevotion: why PACKAGE_INSTALL and not IMAGE_INSTALL?10:05
*** dqx <dqx!~dqx@unaffiliated/dqx> has quit IRC10:05
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto10:06
evotionRP: Because its a custom image that is used on another partition than the actual rootfs. But I tried it on another image using IMAGE_INSTALL and had the same problem.10:13
RPevotion: there are signs something odd is going on since your do_deploy excludes DATETIME yet you don't reference it anywhere. If DATETIME was a key part of the PV and you disable it, that would stop it rebuilding.10:15
RPevotion: its also odd to have do_deploy and use the ipk10:15
kanavinaehs29, it was easier to work on the update that way, I do not like having it all mixed up with other recipes in the same folder10:15
RPevotion: so things don't quite add up but its hard to say why10:15
kanavinRP: I don't object, although I have a preference for keeping it in its own folder separate from other recipes10:15
*** didile <didile!b07ff51a@gateway/web/freenode/ip.> has joined #yocto10:16
*** dqx <dqx!~dqx@unaffiliated/dqx> has joined #yocto10:16
RPkanavin: python-sanity isn't a good choice of name for that :/10:16
kanavinRP: we should probably do the same for perl then, there is a perl-sanity folder currently10:16
RPkanavin: yes, that is also something I'm planning to change10:17
*** lfa <lfa!> has joined #yocto10:17
*** learningc <learningc!> has quit IRC10:20
*** nayfe <nayfe!uid259604@gateway/web/> has quit IRC10:33
evotionRP: The DATETIME is excluded for do_deploy. Running bitbake with the recipe for the package, the do_install and do_deploy is rerun and the ipks are rebuilt. Building directly the image or after rebuilding the package, does not refresh the image. Doing this with another package, leeds to a rebuild of the image.10:34
*** berton <berton!~berton@> has joined #yocto10:36
*** berton <berton!~berton@> has quit IRC10:41
*** berton <berton!~berton@> has joined #yocto10:44
RPevotion: you mean "bitbake <image>" does nothing or that the image rebuilds but doesn't contain the new firmware?10:45
RPevotion: *why* is DATETIME excluded for do_deploy?10:46
RPevotion: why do you even need do_deploy if the fimware is in the image?10:46
RPevotion: This feels like we've only got part of the story. What you say doesn't make sense and the there are several things which clearly don't add up. Not sure how we can help given that :(10:47
*** nayfe <nayfe!uid259604@gateway/web/> has joined #yocto10:47
evotionRP: Running bitbake <image> does trigger a rebuild of the package. The ipk has the correct version of the package, but the file in the image does not get updated. Running bitbake -v <image> i see do_populate_sysroot_setscene, do_deploy_setscene, do_package_write_ipk_setscene and do_packagedata_setscene.10:54
RPevotion: does "bitbake <image> -e | grep PACKAGE_INSTALL=" show you the entry you think it does?10:58
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto10:58
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto10:58
RPevotion: does "bitbake <image> -g" and looking at show a dependency on your firmware recipe from the image do_rootfs ?10:58
*** florian_kc is now known as florian10:59
evotionRP: Both show the dependency to the firmware.11:00
evotionRP: bitbake <image> -g shows a runtime depends11:00
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto11:07
*** fl0v0 <fl0v0!> has quit IRC11:08
*** comptroller <comptroller!> has joined #yocto11:13
*** varjag <varjag!> has quit IRC11:14
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto11:22
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto11:23
*** no_such_user <no_such_user!> has joined #yocto11:48
*** dqx <dqx!~dqx@unaffiliated/dqx> has quit IRC11:53
*** agnem <agnem!> has joined #yocto11:54
yoctiNew news from stackoverflow: spi slave on imx8qmlpddr4arm2 board using yocto <>11:58
*** dqx <dqx!~dqx@unaffiliated/dqx> has joined #yocto11:59
RPevotion: should work then12:02
evotionRP: I thought it could be some missing sstate dependency missing, that does not retrigger the image build. Doing a cleansstate works also12:07
*** varjag <varjag!> has joined #yocto12:12
*** jmiehe <jmiehe!> has quit IRC12:19
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC12:22
RPevotion: something doesn't make sense here :(12:23
rburtoni'd start by deleting all the deploy bits12:24
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:33
evotionrburton: I tried this, but does not make any difference12:34
rburtonwhats't the recipe without the deploy bits in?12:36
evotionrburton: This is the new recipe
rburtondoes the PV strictly increase?12:46
rburtonalso no need for pakagearch=all if you inherit allarch12:46
rburtonFILES should be /firmware/${HEX_INSTALL_NAME}12:47
* psaavedra[m] sent a long message: < >12:49
*** saraf <saraf!~a_saraf@> has joined #yocto12:49
evotionrburton: The PV can also decrease especcially when testing.13:04
evotionrburton: Normaly it increases only.13:04
*** edgar444 <edgar444!uid214381@gateway/web/> has quit IRC13:06
*** jobroe <jobroe!~manjaro-u@> has quit IRC13:06
rburtonso does it not rebuild the image when asked, or does it rebuild with the wrong content13:06
*** berton <berton!~berton@> has quit IRC13:06
evotionIt does rebuild the package, but does not change the content in the image13:06
evotionI'll try to only increase the package13:07
rburtonand when that happens you did ask bitbake to rebuild the image too right13:07
rburton(just building the firmware recipe won't rebuild everything that depends on it)13:08
rburtonie you're doing bitbake myimage (which depends on the firmware)13:08
evotionYes I just run bitbake <image> and that leeds to a rebuild of the firmware13:08
rburtoncheck deploy dir and verify the right package is in there13:09
rburton(with the right content)13:09
rburtonimages are built from package, so check the packages and see what is happening13:09
rburtonif the package if fine then you know its rootfs construction that is not doing what you expect13:10
evotionrburton: rootfs is not retriggered when running bitbake <image>, the ipk package is rebuilt and the content is also correct.13:15
RPevotion: Either the sstate checksum of the do_package_write_ipk task didn't change (in which case it wouldn't rebuild), or the rootfs isn't depending on it13:16
RPevotion: you've stated it does change and the rootfs does depend on it. So either we don't understand the system, bitbake is broken, or one of these things isn't true13:17
*** u1106 <u1106!~quassel@> has quit IRC13:18
*** u1106 <u1106!~quassel@> has joined #yocto13:18
*** edcragg <edcragg!> has quit IRC13:19
*** yourfate <yourfate!~yourfate@unaffiliated/yourfate> has quit IRC13:19
evotionRP: The ipk changes, the content of the image does not, but the dependency is there (it also gets rebuild).13:19
RPevotion: so bitbake is broken or I don't understand the system13:19
*** yourfate <yourfate!~yourfate@unaffiliated/yourfate> has joined #yocto13:20
RPevotion: keep in mind nobody else is seeing such a problem and I was the author for large parts of sstate13:20
evotionRP: Indeed the do_package_write_ipk checksum in stamps does not change between the two builds13:21
evotionRP: We have to use krogoth, was there any bug you know about?13:22
RPevotion: right, so there is some problem in the firmware recipe rather than the rootfs code13:22
RPevotion: krogoth had lots of bugs :(13:22
RPevotion: We've moved on a lot since then13:22
RPevotion: are you using any other varpdeps* flags you're not telling us about?13:23
evotionRP: No, this is the complete recipe.13:24
RPevotion: have you tried setting PV automatically, PV = "X.X+svn${SRCPV}" ?13:25
*** AndersD_ <AndersD_!> has quit IRC13:25
RPevotion: you're using autorev but haven't tied the PV to the automatic revisions13:25
evotionRP: I'll try to build just that image with sumo, to check if it is a bug.13:25
RPevotion: I suspect this is something to do with how you're setting PV and that it isn't rebuilding13:26
sb79aHi, I want to print out the yocto documentation, is there any kind of PDF format?13:27
*** edcragg <edcragg!> has joined #yocto13:27
RPsb79a: the docs Makefile used to be able to generate a pdf at least...13:27
RPsb79a: its docbook based so I'm sure it can be generated13:27
sb79aok thanks, I will do it in this case13:28
*** AndersD <AndersD!~AndersD@> has joined #yocto13:28
evotionRP: Is the recipes filename version used to determine PV or SRCPV?13:32
RPevotion: filename by default13:32
RPevotion: you have to set it to use SRCPV13:32
PinkSnakeHello all, someone here knows the syntax for arithmetic operation on Yocto variable ? (eg. BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count() / 2 }"13:32
*** tasslehoff_ <tasslehoff_!~Tasslehof@> has quit IRC13:33
RPPinkSnake: its python13:34
RPBB_NUMBER_THREADS ?= "${@  <python here> }"13:34
PinkSnakeRP: ok thx i will take a look thx13:36
*** jij <jij!jonashg@nat/axis/x-ngovvzmlpdgutjfn> has quit IRC13:51
*** no_such_user <no_such_user!> has quit IRC13:55
*** jij <jij!jonashg@nat/axis/x-lnsqdwfftsqogdem> has joined #yocto13:59
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto14:03
evotionRP: Thanks for your help. I'll give it a try.14:17
* zeddii has to remember to make zeddii_home -> zedii later today.14:18
*** evotion <evotion!d918c92f@gateway/web/freenode/ip.> has quit IRC14:21
*** nayfe <nayfe!uid259604@gateway/web/> has quit IRC14:23
*** kristoiv <kristoiv!~kristoiv@> has joined #yocto14:23
RPzeddii: switching machines around was a nightmare for me :/14:25
kanavinRP: I compared build times for core-image-minimal (no sstate) with and without virgl/gtk - it does go up from 28 to 32 minutes14:25
RPkanavin: ah, that is useful to know thanks. I was going to try and test this on the autobuilder too!14:26
RPkanavin: just have to fix the scripts first14:26
kanavinRP: you're welcome. I really tried super-hard to make the current sdl frontend work, but it either crashes, or shows a blank screen. Not sure why this hasn't been noticed upstream.14:27
zeddiiRP: indeed.  I did my last set of patches from my new machines, to see what I had missed .. and did find a few things!14:28
RPkanavin: I guess its something which just doesn't get tested :(14:28
kanavinRP: I also tested with qemu provided by fedora and opensuse, and they both have the same 'blank screen' problem as our qemu, when using sdl14:28
kanavingtk on the other hand is fine14:28
RPkanavin: should we report it to them?14:29
RPkanavin: I do want ross to look this one over so we're waiting on him having time for that14:30
kanavinRP: I'm not sure I would have time to follow up on the bug report to be honest14:30
RPkanavin: ok, fair enough14:31
didileI've trouble to package a recipe I wrote with a DEPENDS as another recipe I wrote14:32
didilethe dependence is a C library14:33
*** TobSnyder <TobSnyder!> has quit IRC14:33
didileI get this error: "vesta-app-2.0.0-r0 do_package_qa: QA Issue: /home/root/VestaApp/VestaApp contained in package vesta-app requires, but no providers found in RDEPENDS_vesta-app? [file-rdeps]"14:33
didileI've DEPENDS = "monocypher" in vesta-app_2.0.0.bb14:34
didileand this recipe as
didilewhat's wrong with it?14:37
RPdidile: you had to set FILES? that suggests the library layout isn't standard?14:38
RPdidile: it may be the auto library dependency code isn't handling that and hence you need to set RDEPENDS_vesta-app manually?14:39
*** didile_ <didile_!b07ff51a@gateway/web/freenode/ip.> has joined #yocto14:40
didile_RP: I've added FILES_${PN} = "${libdir}/*.so*" and INSANE_SKIP_${PN} = "ldflags" (see my recipe here:
*** didile <didile!b07ff51a@gateway/web/freenode/ip.> has quit IRC14:42
*** csanchezdll <csanchezdll!> has left #yocto14:46
RPdidile_: I know, that why I commented on it14:47
RPdidile_: I'm wondering why the default FILES didn't work14:47
*** varjag <varjag!> has quit IRC14:48
*** edcragg <edcragg!> has quit IRC14:52
didile_RP: I'm on sumo14:53
*** edcragg <edcragg!> has joined #yocto14:53
*** kristoiv <kristoiv!~kristoiv@> has quit IRC14:54
didile_RP: maybe this is a confusion between $prefix and $libdir?14:55
RPdidile_: FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS}  is the default (from bitbake.conf)14:56
RPSOLIBS = ".so.*"14:56
RPdidile_: so I stand by what I said, it seems your versioning in this recipe is different and its likely confusing the automatic dependency generation code14:57
RPdidile_: have you tried adding an RDEPENDS manually?14:57
didile_RP: yes I've tried RDPENDS with "monocypher" or "libmonocypher"14:58
didile_RP: but no luck :(14:58
didile_RP: maybe I need to use FILES += instead if FILE = ?14:58
RPRDEPENDS_vesta-app += "monocypher" ?14:58
didile_RP: RDEPENDS_${PN} += "monocypher"14:59
didile_I have DEPENDS = "qtwebengine qtwebchannel monocypher" actually15:00
didile_only monocypher gives me this error15:00
didile_because it's probably a bad recipe (it's mine)15:00
RPdidile_: check that the monocypher packages have the correct contents I guess15:00
*** AndersD <AndersD!~AndersD@> has quit IRC15:00
RPdidile_: I tend to worry when you have to deviate from the defaults like FILES15:01
didile_RP: what's the way to check that?15:02
didile_bitbake -c devshell monocypher ?15:02
RPdidile_: look at the contents of the ipk files it generates? (or the packages-split directories in workdir)15:02
didile_RP: maybe there is a way to look at the generated sysroot?15:02
*** dagmcr <dagmcr!sid323878@gateway/web/> has joined #yocto15:03
didile_RP: where are packages-split directories?15:04
didile_RP: I've found only 3 packages-split directories in work/ directory but none for monocypher15:05
RPdidile_: rm_work enabled?15:11
didile_RP: if I run a find command in the tmp directory I get this output: (
didile_RP: yes it is15:11
RPdidile_: it'll have cleaned up those files then15:11
didile_RP: ok15:12
RPdidile_: I come back to the question, why you need that FILES line. The lib names don't look that unusual15:12
didile_RP: I removed it15:12
didile_RP: just now15:12
didile_RP: it's not responsible for this error15:14
RPdidile_: clearly not, but helps to rule it out and clean up your recipe15:14
didile_RP: right15:14
RPdidile_: you skip the ldflags warning. I wonder if there is are flags in there you need15:15
didile_RP: I removed it to see what happen15:17
didile_RP: without it I have another error at some point but it doesn't change the current error15:17
RPdidile_: if "bitbake monocypher" doesn't build cleanly without warnings, sort that out first15:19
RPdidile_: we add these warnings for reasons15:19
furywhat do i delete from a build directory to leave the configuration intact in case i want to rebuild it later? just rm -rf cache tmp?15:20
furymy sstate-cache and downloads are in a separate dir and i always leave those unless i'm desperate for space...15:21
didile_RP: I get: "monocypher-2.0.5-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary: 'tmp/work/cortexa9hf-neon-poky-linux-gnueabi/monocypher/2.0.5-r0/packages-split/monocypher/usr/lib/' [ldflags]"15:21
didile_RP: the line INSANE_SKIP_${PN} = "ldflags" fixes it15:22
RPdidile_: it doesn't fix it, it hides the warning15:24
RPdidile_: I'm wondering if the lack of ldflags means the binary is in a form which the dependency code isn't understanding15:24
RPfury: tmp is the large one and safe to remove. cache isn't large but is usually safe unless you have prserv data in there15:25
furyRP: thanks!15:26
didile_RP: I don't see the need for ldflags in the Makefile15:27
khemRP: I have got LTO working for llvm but it really takes loooong time to compile llvm however, the runtime gains are almost double speed15:27
khemeven Thin-LTO the compile time for llvm is 2.5times :)15:28
furyi have a 512 gig SSD and i keep needing to trim old builds, usually i just delete the whole build directory because i've not customized the config at all, but this one's unique (suppose that means i should script the config mods so i can safely delete the whole build dir :P)15:28
khemfury: usually deleting tmp/ and then running openembedded-core/scripts/ -d -y --cache-dir=$OE_BASE/build/sstate-cache15:29
khemto keep the disk-size in check15:29
khemI have 500G SSD as well, it lasts me a week, but I do crazy things which is not normal15:30
khemMaybe I should use gold to link llvm always hmmm15:30
furythat's a neat script! my sstate-cache dir is about 120 gigs by now, wonder what the script will do to it... (running now, but prolly a bad idea as i'm also building a new image for beaglebone :P)15:33
didile_RP: I followed this article:
*** kristoiv <kristoiv!> has joined #yocto15:34
didile_RP: and the like  TARGET_CC_ARCH += "${LDFLAGS}"  solved this specific issue15:35
*** zagor <zagor!~zagor@rockbox/developer/Zagor> has quit IRC15:35
furyi'm asking santa and/or the IT department for a new 500 gig drive so i don't have to delete so much - since i'm playing with so many images/boards, i inevitably have to rebuild one i deleted 3 or 4 trims ago, so if i had one more drive to put them on, i wouldn't need to rebuild so much15:35
didile_RP: the line*15:35
didile_RP: bitbake monocypher works15:36
didile_RP: but I still have the REDEPENDS_vesta-app error15:36
*** peacememories <peacememories!~textual@2a02:8388:8480:fd80:d10:2309:8032:259c> has joined #yocto15:37
*** cvasilak <cvasilak!> has quit IRC15:37
PinkSnakedidile_: for the GNU_HASH issue, add ${LDFLAGS} to the $CC command ;)15:45
didile_RP: I think that TARGET_CC_ARCH += "${LDFLAGS}" does that15:46
didile_PinkSnake: I think that TARGET_CC_ARCH += "${LDFLAGS}" does that15:46
PinkSnakedidile_: I have tested also and both seems to work, you're right15:46
RPdidile_: If you make it RDEPEND on monocypher-dev does it "solve" the warning?15:48
RPdidile_: I'm wondering if its linking against the unversioned .so instead of the versioned one15:48
didile_RP: I added monocypher-dev to RDEPENDS_${PN} without success :(15:50
didile_RP: this is not a warning but an error: "ERROR: vesta-app-2.0.0-r0 do_package_qa: QA Issue: /home/root/vesta-app/vesta-app contained in package vesta-app requires, but no providers found in RDEPENDS_vesta-app? [file-rdeps]"15:50
didile_I changed VestaApp for vesta-app because of this post:
didile_RP: maybe the "-" character is also forbidden like the uppercase characters...15:53
*** rburton <rburton!> has quit IRC15:55
*** zeddii <zeddii!~bruce@> has left #yocto15:56
*** rburton <rburton!> has joined #yocto15:57
*** zeddiii <zeddiii!> has joined #yocto15:57
*** peacememories <peacememories!~textual@2a02:8388:8480:fd80:d10:2309:8032:259c> has quit IRC15:58
RPdidile_: its no15:59
didile_RP: yes that's right (I tried)15:59
RPdidile_: if you install vesta-app into bindir do you see this error?16:00
*** prabhakarlad <prabhakarlad!~prabhakar@> has left #yocto16:00
RPdidile_: there is something odd about your case as the dependency code usually works but quite what is wrong I don't know16:01
didile_RP: ok16:01
*** stephano2 <stephano2!~stephano@> has quit IRC16:03
RPdidile_: you could also try looking at (and/or sharing) the do_package logs for both the app and the lib. there are lines in there like LIBNAMES: and the section "calculating shlib requirements"16:04
*** kristoiv <kristoiv!> has quit IRC16:05
*** Crofton|work <Crofton|work!~Crofton@2601:5c0:c100:b84:1c14:fc57:7e41:92a0> has quit IRC16:06
*** sno <sno!> has quit IRC16:08
didile_RP: same if I install vesta-app into bindir: "ERROR: vesta-app-2.0.0-r0 do_package_qa: QA Issue: /usr/bin/VestaApp contained in package vesta-app requires, but no providers found in RDEPENDS_vesta-app? [file-rdeps]"16:09
*** zeddiii <zeddiii!> has quit IRC16:10
didile_RP: the logs of the do_package_qa task:
RPdidile_: I said do_package, not package_qa16:13
didile_RP: the logs of the do_package task of monocypher:
*** zeddii <zeddii!> has joined #yocto16:13
RPdidile_: arm-poky-linux-gnueabi-objdump: 'poky/build-neo/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/monocypher/2.0.5-r0/packages-split/monocypher-dev/usr/lib/': No such file16:14
didile_RP: the logs of do_package for vesta-app:
RPdidile_: that looks bad16:14
didile_RP: yes16:14
RPdidile_: probably a bad symlink, try fixing that16:15
didile_RP: in the makefile:
didile_RP: I guess this line "ln -s $$(basename $<) $@"16:17
didile_RP: for the rule lib/libmonocypher.so16:18
RPdidile_: first question, is the symlink bad?16:21
didile_RP: I don't known if it's "bad":
didile_RP: there is only and a pkgconfig directory inside /monocypher-dev/usr/lib/16:28
*** PinkSnake <PinkSnake!51ff1123@gateway/web/freenode/ip.> has quit IRC16:34
didile_RP: the logs of monocypher do_compile:
*** nighty- <nighty-!> has quit IRC16:37
RPdidile_: so where is ?16:40
*** ankit <ankit!c0374fa5@gateway/web/freenode/ip.> has joined #yocto16:41
*** sray <sray!c7a8975e@gateway/web/freenode/ip.> has joined #yocto16:41
didile_RP: in the sources dir (git/lib/
RPdidile_: ah, you mean is in  /monocypher/usr/lib/ ?16:42
ankithi, how do I fetch/write recipes for git lfs based project16:42
didile_RP: I'm wrong you said sorry16:42
didile_RP: it's in /packages-split/monocypher/usr/lib/
didile_RP: and is only in /packages-split/monocypher-dev/usr/lib/libmonocypher.so16:43
*** saraf <saraf!~a_saraf@> has quit IRC16:44
RPdidile_: what does ls -la tmp/work/cortexa9hf-neon-poky-linux-gnueabi/monocypher/2.0.5-r0/image/usr/lib show ?16:44
RPdidile_: it looks ok to me, that error is almost certainly the problem, just a question of why16:46
didile_RP: ok16:46
didile_RP: I'll investigate on monday16:46
didile_RP: thanks for your help :)16:46
srayNoob here, trying to use devtool to update python recipe. See error about "Task do_create_manifest ... depends on non-existent task do_patch ..."16:54
sraywhen running `devtool build`16:54
sraythe example `nano` devtool workflow works okay, but obviously doesn't have any patches being applied in the recipe16:55
*** sjolley <sjolley!> has joined #yocto16:57
*** didile_ <didile_!b07ff51a@gateway/web/freenode/ip.> has quit IRC16:58
ankithello, how to fetch git lfs based package. Appreciate help16:59
rburtonsray: python is *hard* to upgrade, don't bother basicall17:03
rburtonthere's patches on the list right now to update to 3.717:04
kanavinrburton: already in master \0/17:04
*** lusus <lusus!~lusus@> has quit IRC17:04
srayAh thanks :) I was seeing what was possible with devtool, I do have those 3.7 patches. I'll go that route instead. Thank you.17:05
*** tprrt <tprrt!~tprrt@> has quit IRC17:06
srayDo you know if this is just a general issue with devtool, that it doesn't support recipies with patches in them?17:08
kergothno, it's not a general issue17:12
kergothdevtool was designed to work with patches17:12
kergothof course, there's no guarantee they'll all apply after the upgrade, but taht's true whether you use devtool for the upgrade or not17:12
srayHrm.. so why does it fail to find the do_patch method? It looks like there is a missing include/lib or something like that17:13
kergothdo_create_manifest is the issue, which doesn't exist anywhere else17:13
kergoththat's python specific17:13
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC17:14
*** adrianbunk <adrianbunk!> has quit IRC17:14
srayOkay, good to know. I appreciate the help!17:15
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC17:16
srayIs it terrible to use the tip of master for developing against now? Assuming we pin the commit etc, until the next release with Python 3.7.x is out? I'm not sure how stable it is and what other pain points that might cause17:22
kanavinsray, that's a question that can only be answered by trying it out17:23
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC17:23
kanavinmaster does get tested17:23
srayIgnore that question :) I wasn't thinking about the layer name dependencies for third party layers etc.17:23
*** Bunio_FH <Bunio_FH!> has quit IRC17:24
*** paulg <paulg!> has quit IRC17:28
srayDo you know when the `thud-next` tag gets updated?17:31
kergothwhenever the thud maintainer updates it :)17:31
srayHa! that is fair :)17:34
*** mckoan is now known as mckoan|away17:42
*** stacktrust <stacktrust!> has quit IRC17:42
*** sray <sray!c7a8975e@gateway/web/freenode/ip.> has quit IRC17:49
*** tprrt <tprrt!> has joined #yocto18:06
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC18:09
RPhmm, all our do_package logs are filled with those file not found messages :(18:18
halsteadRP, AB maintenance is complete and ready for work.18:32
*** falk0n <falk0n!> has quit IRC18:41
kanavinfray, yet another gitsm issue found18:41
kanavinwe have a broken recipe here which lists multiple gitsm uris in SRC_URI and doesn't set SRCREV_FORMAT18:42
kanavinthen SRCPV fails to expand, and this isn't properly caught by the unpack task18:42
kanavinwhich results in a generic unhelpful failure18:43
kanavinI sent a patch to bitbake-devel for this18:43
*** AndersD <AndersD!> has joined #yocto18:44
*** AndersD_ <AndersD_!> has joined #yocto18:46
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:46
*** AndersD <AndersD!> has quit IRC18:48
*** sb79a <sb79a!> has quit IRC18:49
*** sb79a <sb79a!> has joined #yocto18:50
*** sb79a <sb79a!> has quit IRC18:54
*** robbawebba <robbawebba!~rob@> has quit IRC18:59
RPhalstead: thanks, I'll fire a -next build19:04
RPhalstead: I held off earlier :) Its running now19:06
RPkanavin: do we need a new test case?19:06
halsteadRP, Thank you. I went to execute the graceful shutdown we talked about but it was already idle. :)19:07
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto19:21
*** WillMiles <WillMiles!> has joined #yocto19:25
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto19:30
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC19:57
yoctiNew news from stackoverflow: How do I generate an ordered lists of the executed tasks when bitbaking a package? <>20:00
*** AndersD_ <AndersD_!> has quit IRC20:00
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC20:01
*** sb79a <sb79a!> has joined #yocto20:08
*** sb79a <sb79a!> has quit IRC20:12
khemRP: do we use xz for sstate now ? or still gzip20:23
khemI see tar -czS -f being called20:23
*** sb79a <sb79a!> has joined #yocto20:40
*** sb79a <sb79a!> has quit IRC20:45
*** behanw <behanw!uid110099@gateway/web/> has joined #yocto21:03
*** ankit <ankit!c0374fa5@gateway/web/freenode/ip.> has quit IRC21:13
*** sno <sno!> has joined #yocto21:22
*** ferlzc <ferlzc!~ferlzc@> has quit IRC21:24
*** zeddii_home <zeddii_home!> has quit IRC22:03
*** zeddii_home <zeddii_home!> has joined #yocto22:07
*** dev1990 <dev1990!> has joined #yocto22:10
*** zeddii_home <zeddii_home!> has quit IRC22:12
*** maudat <maudat!~moda@> has quit IRC22:17
*** radsquirrel <radsquirrel!> has joined #yocto22:18
*** sno <sno!> has quit IRC22:21
*** sno <sno!> has joined #yocto22:23
*** vmeson <vmeson!> has quit IRC22:24
*** tprrt <tprrt!> has quit IRC22:29
*** vmeson <vmeson!> has joined #yocto22:32
*** schnitzeltony <schnitzeltony!5de68cd6@gateway/web/freenode/ip.> has joined #yocto22:32
RPkhem: gzip for speed iirc22:34
RPkhem: parallel gzip is a lot faster22:34
khemRP: ok, so we use parallel gzip ?22:36
khemRP: I am seeing xz eating up memory since it threads too much :)22:36
khemon machines with 16cores/15GB ram xz gives up on some monsterous recipes22:36
khem16GB I mean22:37
*** luq <luq!> has quit IRC22:37
RPkhem: it uses pigz if available22:39
schnitzeltonyhi - khem: Would you mind to add multilib on your autobuilder?22:48
khemschnitzeltony: I think thats a good idea, I could do it for x86_64 build, but I am afraid it will end up with failures that no one will fix and will fall on to me22:50
schnitzeltonyYou'll have me on your side :) - most fixes are simple22:51
*** agust <agust!> has quit IRC22:52
*** WillMiles <WillMiles!> has quit IRC22:53
schnitzeltonyI think the problem is people are not aware - for example ${PN} in SRC_URI22:53
*** vmeson <vmeson!> has quit IRC22:54
khemschnitzeltony: let me see what I can do22:56
khemRP: so pigz on build host ? or can it use pigz-native ?22:56
RPkhem: both would work if available22:57
RPkhem: the sstate code simply uses pigz from PATH if available22:57
*** vmeson <vmeson!> has joined #yocto22:58
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto23:00
*** JaMa <JaMa!~martin@> has joined #yocto23:00
*** rburton <rburton!> has quit IRC23:02
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC23:02
schnitzeltonykhem: I know it is yet another burden put upon you: How about more details on autobuilder results e.g if a recipe fails not for 'common' I don't know: is it musl related / clang (or multilib once tested)23:03
RPkhem: did you end up using any of the config driver code for it? I've been planning a "reproduction" tool for failing OE-Core builds using the helper repo23:06
khemRP: no not yet23:18
khemschnitzeltony: the jenkins builds use gcc/glibc/musl/system combos23:19
khemschnitzeltony: my own builds use clang in some cass23:19
khemthere are so many combinations we can go nuts23:19
RPkhem: I'm sure we're all quite nuts by now! ;-)23:20
khemRP: I think Ross also came across this in past but I was enablinh LTO and found that we need to use COMPILER_AR and COMPILER_NM and COMPILER_RANLIB23:21
RPkhem: he did run into it, yes23:22
khemRP: I was wondering if we should make default AR/NM/RANLIB point to this once for all23:22
RPkhem: he had patches but I think you weren't keen23:22
khemsince with binutils 2.32 I dont have many concerns with that23:22
khemclang when compiled with lto can compile 1.5x faster23:23
khemI was wondering if we can enable system-wide LTO the image could get similar benefits23:23
khemand code is smaller too23:23
khembut build time is longer but thats the compromize23:23
khemI believe its ok to spend some time compiling the compiler which will compile the rest of system faster and compile rest of system with LTO as well and spend some time doing so, such that the resulting code will be smaller and faster which will run on targets23:24
khemI dont know if I made sense there but anyway thats the nuts part23:25
RPkhem: I'd like to try our build time perf tests with this enabled23:25
khemthats a good idea23:26
RPkhem: can't see ross' patch in his branches23:28
RPkhem: he just talked about his test on list afaict23:28
RPkhem: anyhow, if we put a branch together I can run it through our perf test on the AB23:29
RPkhem: automatic results aren't quite there but can be done manually23:29
khemRP: world might not compile with lto23:31
khembut if we can test images I think that will be a good start23:31
RPkhem: core-image-sato is our timing test target23:36
RPkhem: btw, I'd tweaked the space in that glibc-locale patch. I only just read you had other tweaks after I'd merged the other one :/23:38
* RP -> Zzzz23:39
khemRP: not to that recipe but other oe-core changes23:40
khemlike libunwind patch23:40
khemI sent just now23:40
*** sb79a <sb79a!> has joined #yocto23:42
*** schnitzeltony <schnitzeltony!5de68cd6@gateway/web/freenode/ip.> has quit IRC23:42
*** sb79a <sb79a!> has quit IRC23:46

Generated by 2.11.0 by Marius Gedminas - find it at!