Thursday, 2018-12-20

*** apteryx_ <apteryx_!~maxim@> has joined #yocto00:10
*** apteryx <apteryx!~maxim@> has quit IRC00:10
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC00:12
RPkhem: if you can't spot the issue, send me a note of the config and I can try and reproduce and investigate tomorrow00:13
khemRP: ok00:13
khemRP: reproduced with poky00:14
RPkhem: we test esdk heavily with poky, what did you change?00:14
khemRP: clone another layer parallel to poky and then add that layer to bblayers.conf in normal poky build00:14
khemI cloned meta-openembedded parallel to poky00:15
khemthen added meta-openembedded/meta-oe to bblayers.conf00:15
khembitbake -cpopulate_sdk_ext core-image-minimal00:15
khemended in same error as I am seing00:15
khemBBLAYERS ?= " \00:16
khem  /mnt/a/yoe/sources/meta-openembedded/meta-oe \00:16
khem  /home/kraj/work/poky/meta \00:16
khem  /home/kraj/work/poky/meta-poky \00:16
RPkhem: the uninative checksum going missing?00:16
khem  /home/kraj/work/poky/meta-yocto-bsp \00:16
khem  "00:16
RPthe second error is a comparatively well known issue which is a config difference somewhere. The first one is much more unusual00:17
*** varjag <varjag!> has joined #yocto00:17
khemRP: not that one but the second error
khemI see00:17
RPkhem: the second one means it didn't replicate the config enough to get matching task hashes00:18
*** varjag <varjag!> has quit IRC00:21
khemand I think its trying to add layers relative to its own location see ERROR: Layer directory '/home/kraj/work/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/../../../mnt/a/yoe/sources/meta-openembedded/meta-oe' does not exist! Please check BBLAYERS in00:21
*** andycooper <andycooper!uid246432@gateway/web/> has quit IRC00:24
khemRP: my distro does not use oe-init-build-env script at all00:27
khemI wonder if that is a difference00:27
*** yates <yates!> has quit IRC00:30
*** JaMa <JaMa!~martin@> has joined #yocto00:34
*** varjag <varjag!> has joined #yocto00:38
*** rburton <rburton!> has quit IRC00:42
*** rburton_ <rburton_!> has joined #yocto00:42
*** OpenSorceress <OpenSorceress!> has joined #yocto00:42
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto00:42
*** varjag <varjag!> has quit IRC00:43
*** Aethenelle <Aethenelle!Aethenelle@gateway/shell/panicbnc/x-zzaguqozpnatoeba> has joined #yocto01:03
*** anujm <anujm!anujm@nat/intel/x-rkqokxplngmycrey> has joined #yocto01:23
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC01:30
*** rburton_ <rburton_!> has quit IRC01:41
*** rburton <rburton!> has joined #yocto01:43
*** armpit <armpit!~armpit@2601:202:4180:c33:a0ac:ef77:794d:67d9> has quit IRC02:04
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto02:06
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC02:09
*** falstaff <falstaff!~ags@> has joined #yocto02:21
*** sagner <sagner!~ags@> has quit IRC02:21
*** obsrwr <obsrwr!> has joined #yocto02:21
*** obsrwr_ <obsrwr_!> has quit IRC02:24
*** varjag <varjag!> has joined #yocto02:28
*** varjag <varjag!> has quit IRC02:31
*** varjag <varjag!> has joined #yocto02:31
*** varjag <varjag!> has quit IRC02:33
*** armpit <armpit!~armpit@2601:202:4180:c33:b19c:c43d:d2e1:10c> has joined #yocto02:37
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC02:41
*** varjag <varjag!> has joined #yocto03:00
*** varjag <varjag!> has quit IRC03:05
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC03:16
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto03:22
*** anujm <anujm!anujm@nat/intel/x-rkqokxplngmycrey> has quit IRC03:25
*** woky <woky!~woky@2a02:2b88:2:1::e72:1> has left #yocto03:25
*** varjag <varjag!> has joined #yocto03:26
*** varjag <varjag!> has quit IRC03:31
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto03:32
*** rburton <rburton!> has quit IRC03:34
*** rburton_ <rburton_!> has joined #yocto03:34
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC04:06
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto04:06
*** anujm <anujm!~anujm@> has joined #yocto04:08
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC04:27
*** anujm <anujm!~anujm@> has quit IRC04:33
*** mattsm <mattsm!~mattsm@> has quit IRC04:39
*** mattsm <mattsm!~mattsm@> has joined #yocto04:42
*** anujm <anujm!~anujm@> has joined #yocto04:50
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto05:03
erboI saw a mention in the Yocto Ref Manual that rm_work could actually speed up builds. It seems a bit unintuitive to me, but I guess disk caching benefits might be tricky to grasp. Anyone know of benchmarks or so that can show some results?05:29
*** anujm <anujm!~anujm@> has quit IRC05:33
*** apteryx_ is now known as apteryx05:41
*** comptroller <comptroller!> has quit IRC05:51
*** anujm <anujm!~anujm@> has joined #yocto05:52
*** jobroe <jobroe!~manjaro-u@> has joined #yocto06:00
*** comptroller <comptroller!> has joined #yocto06:04
*** AndersD <AndersD!> has joined #yocto06:10
*** AndersD <AndersD!> has quit IRC06:16
*** AndersD <AndersD!~AndersD@> has joined #yocto06:16
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC06:18
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:ed56:6b9e:b5a:7e5a> has joined #yocto06:33
*** halfhalo <halfhalo!halfhalo@nasadmin/webteam/halfhalo> has quit IRC06:34
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has quit IRC06:34
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has joined #yocto06:43
*** anujm <anujm!~anujm@> has quit IRC06:43
*** halfhalo <halfhalo!halfhalo@nasadmin/webteam/halfhalo> has joined #yocto06:45
*** comptroller <comptroller!> has quit IRC06:54
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto06:58
*** sno <sno!> has quit IRC06:59
*** anujm <anujm!anujm@nat/intel/x-yoggbcwxeptnfiax> has joined #yocto07:00
*** tprrt <tprrt!~tprrt@> has joined #yocto07:26
*** frsc <frsc!> has joined #yocto07:35
*** jmiehe <jmiehe!> has joined #yocto07:51
*** lusus <lusus!~lusus@> has joined #yocto07:58
*** fl0v0 <fl0v0!> has joined #yocto08:02
*** sno <sno!> has joined #yocto08:03
*** eduardas_m <eduardas_m!~eduardas@> has joined #yocto08:04
*** hamis <hamis!~irfan@> has joined #yocto08:12
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto08:13
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC08:15
*** varjag <varjag!> has joined #yocto08:28
*** ant_home <ant_home!> has joined #yocto08:28
*** Bunio_FH <Bunio_FH!> has joined #yocto08:39
*** eduardas_m <eduardas_m!~eduardas@> has quit IRC08:46
*** eduardas_m <eduardas_m!~eduardas@> has joined #yocto08:48
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto08:53
*** rubdos <rubdos!> has quit IRC08:56
*** jmiehe <jmiehe!> has quit IRC09:01
*** cquast <cquast!~cquast@> has joined #yocto09:03
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto09:06
RPkhem: ah, it was site/conf?09:09
pepijndevosI have a few git autoinc recipes, but our internal git server is momentarily down. Why is it a fatal error if it can't check for updates? It has all the code.09:15
rburton_RP: want to pull my ranlib thing into next too?09:16
rburton_best give it a nice message09:16
*** gaulishcoin <gaulishcoin!> has joined #yocto09:17
*** gaulishcoin <gaulishcoin!> has joined #yocto09:17
pepijndevosarg.. I can't even build any other recipe, because all the git ones give fatal errors, while they should be up to date.09:20
pepijndevosI found some reference to BB_SKIP_NETTESTS=yes, but this does nothing at all.09:24
RPrburton_: that should be in the next round, yes09:27
*** cvasilak <cvasilak!> has joined #yocto09:29
pepijndevosIs there any way to skip fetching these recipes?09:33
*** sno <sno!> has quit IRC09:37
*** jmiehe <jmiehe!> has joined #yocto09:38
*** sno <sno!> has joined #yocto09:42
*** florian_kc is now known as florian09:45
*** kaspter <kaspter!~Instantbi@> has quit IRC09:52
*** kaspter <kaspter!~Instantbi@> has joined #yocto09:53
rburton_pepijndevos: set srcrev to the current sha you have?09:53
pepijndevosThat would be annoying but workable if the git server stays down for long enough.09:56
pepijndevosDifferent and odd issue: /bin/systemctl does not have execute permission.09:57
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:02
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:03
*** alinucs <alinucs!> has quit IRC10:12
*** alinucs <alinucs!> has joined #yocto10:13
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC10:17
varjagso what happens if there are several .bbappend files to the same recipe?10:29
*** sno <sno!> has quit IRC10:29
varjagall of them are applied in some uncertain order?10:30
LetoThe2ndvarjag: layer priority should apply10:30
varjagso, in order of decreasing PV?10:34
varjagor, wait, should it be increasing10:34
*** sno <sno!~sno@2a01:598:8187:f519:54fc:68b5:7209:8370> has joined #yocto10:36
*** comptroller <comptroller!> has joined #yocto10:42
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto10:49
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto10:55
*** niro22 <niro22!> has joined #yocto10:58
*** rburton_ <rburton_!> has quit IRC11:00
*** rburton <rburton!> has joined #yocto11:00
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC11:03
*** falk0n <falk0n!> has joined #yocto11:06
pepijndevosStupid question that I can't seem to find in the "user" manual with a ton of "user" configuration is how to actually add a custom user, other than passwordless roos11:10
RPpepijndevos: there is an example in meta-skeleton11:15
RPrburton: going to rerun -next with a couple of small tweaks like mingw fix, see if we can get a clean pass before we test more patches11:19
*** cquast <cquast!~cquast@> has quit IRC11:21
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC11:22
*** niro22 <niro22!> has quit IRC11:23
*** sno <sno!~sno@2a01:598:8187:f519:54fc:68b5:7209:8370> has quit IRC11:24
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC11:26
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto11:27
*** Net147 <Net147!~Net147@unaffiliated/net147> has quit IRC11:31
*** Net147 <Net147!~Net147@unaffiliated/net147> has joined #yocto11:31
kanavinrburton: what would be a good GL thing to run that provides better eye candy than glxgears? (preferably available in oe-core)11:56
*** fl0v0 <fl0v0!> has quit IRC11:57
*** fl0v0 <fl0v0!> has joined #yocto11:58
*** armpit <armpit!~armpit@2601:202:4180:c33:b19c:c43d:d2e1:10c> has quit IRC11:59
rburtonkanavin: as a test or what?12:00
rburtoni've been meaning to knock up a recipe for but that's quite a lot larger than glxgears12:01
*** armpit <armpit!~armpit@2601:202:4180:c33:b19c:c43d:d2e1:10c> has joined #yocto12:01
rburtonpretty though12:01
kanavinrburton: both test and demo12:01
rburtonvalley then, it's not open source but free to use12:01
rburtonwell, not commercialy12:02
rburtonwould have to read the terms12:02
kanavinthey also have a couple other benchmarks12:03
rburtontropics is a lot smaller and doesn't say non-commercial12:04
varjagif i have an autotools based recipe, can i still use do_install there?12:06
varjagto install some binary blobs to certain paths12:06
RPrburton: can you look at the last oe-selftest failure. We have a problem in the connection code :(12:10
RPrburton: hmm, triggered by the patch from robert12:12
rburtonvarjag: do_install_append to do your custom bits12:12
RPrburton: oh, they're all racing each other12:13
varjagrburton: thanks. the recipe is mine, i.e. it's not an append file12:13
varjagshould i use do_install_append vs do_install still?12:13
rburtonvarjag: didn't say it was.  yes. you write a do_install_append to append to do_install, which is provided by autotools.bbclass12:13
rburtonthere are other ways, that's the easiest12:13
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto12:14
varjagi see, thanks12:14
rburtonyou could write do_install() and inside it call autotools_do_install and then your stuff12:14
varjagah, so that's how it works12:17
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:21
kanavinrburton: I was wondering why cmake is so slow :)12:39
rburtonwith autoconf had a parallell button!12:39
*** sno <sno!> has joined #yocto12:40
yoctiNew news from stackoverflow: Update the Yocto recipe with devtool <>12:40
kanavinrburton: there are more recipes that we can (and should) convert to meson12:47
kanavine.g. mesa, glib12:47
rburtonkoen has a patch for mesa in progress12:48
kanavinI wonder if there's anything interesting in mesa-demos12:51
*** marka <marka!~masselst@> has joined #yocto12:52
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto13:07
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto13:07
ant_homerburton, heh, when I poked you about mipsel site endianness I did not imagine it would lead to the complete removal of siteconfig :)13:20
rburtonDIE DIE DIE13:20
rburtonpull a thread and look what happens13:20
rburtonvariety of pieces came together13:20
rburtoni benchmarked it a few weeks ago and knew it was not as useful as assumed13:21
rburtonthen RP discovered that the only thing keeping glibc-initial around with siteconfig13:21
ant_homeI'm firing a build to test that13:25
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto13:27
ant_homewith musl actually13:27
ant_homemipsel ;)13:28
RPand then I started looking at why we needed gcc-initial :)13:38
RPrburton: merge the non gcc pieces of -next?13:39
ant_homebtw I read today in one forum that OE suxx because cross-localedef is built with the buildhost headers13:39
ant_homethe -native ofc13:39
ant_homewhat was the problem? they have olg glibc < 2.2813:40
RPant_home: it should probably use target headers13:41
RPant_home: well, hmm. glibc did mess the locale formats around recently :(13:41
RPant_home: or do you mean they were using an old target glibc with a modern cross-localedef ?13:42
ant_homethey are moving to sumo now, I am helping toward thud13:42
RPant_home: if the OE developers are unaware there is a problem its less likely to get fixed13:43
ant_homedoesn't uninative help right here?13:44
RPant_home: uninative doesn't have headers, so no13:44
ant_homeso it looks like host-contamination afais13:45
ant_homeRP: last time I had problems was when gentoo had a strange glibc, years ago. Just once.13:46
RPant_home: - talk to khem but I think we may have sorted this13:46
ant_homeremember they lag years behind :/13:47
RPant_home: yes, I think it could have been fixed13:47
ant_homeI have just told them only minor changes are needed between sumo and thud. Did I lie?13:48
RPant_home: khem's localedef has been around for a long time looking at the history, so no13:50
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto13:54
kanavinrburton: glxgears FPS jumps ten-fold in qemu \0/13:56
kanavinfrom 15ish to 160 or more13:56
T_UNIXrburton: shouldn't meson be provided with the toolchain, if an image's recipe `inherit meson`?.13:57
kanavinoh, and: X rendering is done via glamor, and looks fine13:57
kanavinT_UNIX: meson class is for building software, similar to autotools or cmake classes13:58
T_UNIXi.e. `` contains `include meson`. `foo` is part of `bar-image`. Then `bitbake bar-image -c populate_sdk` should populate the generated sdk with meson, shouldn't it?13:58
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto13:59
T_UNIXkanavin: so I'd need to write another recipe that would `inherit crosssdk`13:59
RPT_UNIX: no :/14:00
RPT_UNIX: "inherit meson" means this recipe uses meson to build, it doesn't have any affect on the sdk14:01
T_UNIXI got that14:01
RPT_UNIX: you'd want to include nativesdk-meson in the SDK through the normal sdk package inclusion mechanism14:02
RPassuming nativesdk-meson exists14:02
RPif it doesn't you'd then need to BBCLASSEXTEND meson to nativesdk14:02
T_UNIXRP afaics it does not exist yet14:02
RPT_UNIX: I see a nativesdk-meson .bb file here14:03
T_UNIXRP: where's is that?14:04
T_UNIXdamn. likely sumo or even newer?14:04
RPT_UNIX: master14:04
rburtonthud has it too14:05
rburtonif you're using an old release, you'll be best to just copy/paste the recipes and classes from thud14:05
rburtonhuh we don't have a meson test for the sdk yet14:06
rburtonRP: permission to add nativesdk-meson to core-image-sato's sdk task sir14:06
RPrburton: if you mean the packagegroup for tools, yes14:06
rburtonthat's the debate: all toolchains?14:07
RPrburton: looking at the other stuff in it and the fact it has minimal depends, nativesdk-packagegroup-sdk-host should be ok?14:08
rburtonyeah just done that14:08
RPrburton: cmake, opkg, unfs314:09
RPthat darwin override looks a bit sad14:09
T_UNIXrburton: RP: thanks :)14:10
rburtonRP: awwww lonely14:10
*** zagor <zagor!~zagor@rockbox/developer/Zagor> has quit IRC14:16
*** hamis <hamis!~irfan@> has quit IRC14:17
*** cquast <cquast!~cquast@> has joined #yocto14:18
*** JaMa <JaMa!~martin@> has quit IRC14:19
*** zagor <zagor!~zagor@rockbox/developer/Zagor> has joined #yocto14:21
*** jobroe <jobroe!~manjaro-u@> has quit IRC14:32
*** mrc3 <mrc3!mrc3@linaro/mrc3> has quit IRC14:33
*** alimon <alimon!alimon@gateway/shell/linaro/x-fuglknstuwqprivu> has quit IRC14:33
*** cquast <cquast!~cquast@> has quit IRC14:34
*** cquast <cquast!~cquast@> has joined #yocto14:36
*** yates <yates!> has joined #yocto14:37
yatesi have matchbox/sato running in a session, and i've updated a desktop file but matchbox/sato doesn't appear to be picking up the mod. is there a way i can get matchbox/sato to update (reload) the .desktop files from the command line?14:38
*** alimon <alimon!alimon@gateway/shell/linaro/x-ixuwdelrhcxlhihq> has joined #yocto14:44
*** falstaff <falstaff!~ags@> has quit IRC14:50
*** mrc3 <mrc3!mrc3@gateway/shell/linaro/x-hdisqbkhenyarvad> has joined #yocto14:51
*** mrc3 <mrc3!mrc3@linaro/mrc3> has joined #yocto14:51
*** falstaff <falstaff!~ags@> has joined #yocto14:57
*** AndersD <AndersD!~AndersD@> has quit IRC14:59
*** joseppc <joseppc!~josep@unaffiliated/joseppc> has joined #yocto15:04
joseppcHi,I am using yocto 2.5, and I get an error when I do "import json" with python3, as if the module was missing, shouldn't it be part of python's standard lib?15:07
*** sno <sno!> has quit IRC15:26
*** Bunio_FH <Bunio_FH!> has quit IRC15:32
*** cvasilak <cvasilak!> has quit IRC15:34
*** kaspter <kaspter!~Instantbi@> has quit IRC15:39
khemRP: yes now its working15:40
*** kaspter <kaspter!~Instantbi@> has joined #yocto15:40
khemRP: i am seeing
*** ilbelkyr <ilbelkyr!ilbelkyr@freenode/staff/atheme.ilbelkyr> has quit IRC15:46
rburtonjoseppc: you probaby failed to install all of python.  install python3 explicitly and you'll get the full runtime15:49
*** ilbelkyr <ilbelkyr!ilbelkyr@freenode/staff/atheme.ilbelkyr> has joined #yocto15:50
joseppcrburton: ok, thanks15:52
*** zagor <zagor!~zagor@rockbox/developer/Zagor> has quit IRC15:54
*** lusus <lusus!~lusus@> has quit IRC15:57
*** sno <sno!~sno@2a01:598:8187:f519:f1cb:6d15:894b:4c02> has joined #yocto16:10
*** didile <didile!b07ff51a@gateway/web/freenode/ip.> has joined #yocto16:10
*** ejoerns <ejoerns!> has quit IRC16:10
*** varjag <varjag!> has quit IRC16:11
didilethe "logging" module isn't installed for python 2.7.1516:20
rburtondid you install all of python?  install 'python' (or python-modules if you're using an old release)16:20
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:21
rburtonkergoth: dude i can't pm you16:21
didileI see all the python tasks in the packages lists for "bitbake -g -u taskexp <image>"16:23
RPkhem: interesting. My aarch64 tests passed. What is different about that build?16:24
khemits using glibc 2.2916:24
didileIn my recipe I've "python-simplejson", "python-subprocess" and "python-psutil" as RDEPENDS packages16:25
*** jmiehe <jmiehe!> has quit IRC16:26
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto16:26
*** rcw <rcw!~rcw@> has joined #yocto16:27
rburtondidile: so you're getting those (and the bits of the core library that they use)16:29
ant_homezeddii, h16:29
rburtondidile: easy fix: just rdepend on python-modules, and you'll get the whole standard library16:29
ant_homesomething wrong with the kernel scripts using musl16:29
rburtondidile: (added to the ones you already have)16:29
ant_homezeddii, any hint?
*** didile_ <didile_!b07ff51a@gateway/web/freenode/ip.> has joined #yocto16:30
didile_should I add "python" as RDEPENDS in my python recipes?16:30
didile_I already use "inherit setuptools"16:32
*** NeilS <NeilS!6140a676@gateway/web/freenode/ip.> has joined #yocto16:32
*** didile <didile!b07ff51a@gateway/web/freenode/ip.> has quit IRC16:32
didile_"logging" is part of the standard python library16:32
NeilSI upgraded to Sumo and a new version of u-boot 4.916:32
*** lucaceresoli <lucaceresoli!> has quit IRC16:32
NeilSand i seem to be running into a build issue16:32
NeilSsays "cc1: warning unknown register name :x1816:33
zeddiiant_home. which kernel version is that ? I've never hit that with my musl build here. i might just not be building the same kernel versions.16:33
ant_homeit's an old mipsel 3.13.516:34
zeddiiholy lag from me typing that to it coming through16:34
* zeddii clearly needs to debug16:34
ant_homestrangely build fails with musl tc16:34
ant_homemaybe it's the initial scripting16:34
ant_homewith musl, the assemble thinks it's a mips316:35
ant_homemaybe bad-cut mips32 ?16:35
ant_home83: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f0,272+016:35
zeddiihmm. interesting.16:36
ant_homeboth gcc's clearly pass -mel -mabi=32 -mhard-float -march=mips3216:36
RPkhem: ah, so its failing with 2.29? Not good16:39
apteryxhow can I mute this 'your distro is not supported blablabla warning'?16:44
RPapteryx: SANITY_TESTED_DISTROS = ""16:44
*** lucaceresoli <lucaceresoli!> has joined #yocto16:45
ant_homeRP: so new tc w/out *initial is failing with glibc 2.29?16:45
*** lucaceresoli <lucaceresoli!> has quit IRC16:45
ant_homeI tested both separately...16:45
RPant_home: for aarch64 for khem16:45
ant_homeI see16:46
apteryxRP: am I supposed to just export this env var? Or is it a config to be written to a specific file?16:47
khemRP: its working on my local box though which uses gcc9+glibc2.29  so maybe glibc 2.29+gcc8+latest-toolchain-changes is the problem16:55
ant_homezeddii, the Makefiles are equal16:55
khemRP: I know glibc 2.29 worked across all arches few days ago16:56
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:ed56:6b9e:b5a:7e5a> has quit IRC16:56
*** didile_ <didile_!b07ff51a@gateway/web/freenode/ip.> has quit IRC16:57
tlwoernerwhy have so many YP Engineering Sync meetings been canceled? (e.g. Feb 5, Mar 5, Apr 2)17:03
*** ant_home <ant_home!> has quit IRC17:03
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC17:04
tlwoernerare the technical team meetings for those days also canceled?17:04
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC17:05
RPkhem: very odd :(17:05
RPtlwoerner: I suspect Stephen is trying to cancel the one next week17:12
tlwoernerRP: with a shotgun, apparently ;-)17:13
khemtlwoerner: you dont support automatic weapons :)17:13
khemzeddii: did you pickup aarch64 fixes for kernel,17:13
khemRP: I am testing a lot of combinations, I guess once the toolchain sequence changes settle in and we look to upgrade glibc to 2.29 we might see it or if you have AB cycles throw 2.29 in and see if you can reproduce it too17:15
*** falstaff <falstaff!~ags@> has quit IRC17:16
*** joseppc <joseppc!~josep@unaffiliated/joseppc> has quit IRC17:17
zeddiikhem. I have them queued, was it just the 3 patch series you pointed me at yesterday ?17:17
khemyes, that will make my musl builds on aarch64 lot greener17:18
zeddiiok. I'll finish up my testing and send them out ASAP.17:19
*** varjag <varjag!> has joined #yocto17:19
khemty zeddii17:21
NeilSHi, I am seeing this as a build error when i try to build my image17:22
NeilSu-boot-controltech/2017.03-r0/git/scripts/ recipe for target 'arch/arm/cpu/armv8/exceptions.o' failed make[2]: *** [arch/arm/cpu/armv8/exceptions.o] Error 117:22
khemNeilS: the error should be up in logs as to what compiler is saying17:22
NeilSlet me check17:23
NeilSstarts here i guess Error: bad instruction `stp x29,x30,[sp,#-16]!'17:25
NeilSthere are a bunch of cc1: warning: unknown register name: x18 before that17:26
khemare you using 32bit compiler by any chance ?17:26
khemor passing -mabi flag which turns on 32bit17:27
NeilSI just changed it so instead of using the 2015 uboot it build the 2017.. So i haven't really changed any flags just branches and revisions17:29
khemhmm then it must be in the Makefiles etc. of uboot17:29
NeilScan i force the right flags in the recipe or environment variables?17:29
khemthat instr is a valid for 64bit arm17:29
NeilSok.. this uboot is from variscite. They might know something or have a patch17:33
*** zeddii <zeddii!~bruce@> has quit IRC17:52
*** tprrt <tprrt!~tprrt@> has quit IRC17:54
RPkhem: FWIW MACHINE=qemuarm64 bitbake glibc with 2.29 worked here17:57
*** niro22 <niro22!> has joined #yocto17:58
RPJPEW: I put a patch for mingw in master-next for the gcc-initial changes18:00
RPJPEW: it passed testing18:00
*** fl0v0 <fl0v0!> has quit IRC18:01
khemRP: thats a good news18:11
*** King_InuYasha is now known as Conan_Kudo18:11
*** Conan_Kudo is now known as King_InuYasha18:11
khemRP: that only means its self-inflicted pain somewhere for me :) I will figure it18:11
khemRP: can I get a full test run with glibc 2.29 when ABs can18:12
khemRP: this will make it smooth slip in for glibc 2.29, since gcc 9 will come out around in April so its good to settle the big boulders early18:14
khemSupport for the Armv5 and Armv5E architectures (which have no known implementations) has been removed. Note that Armv5T, Armv5TE and Armv5TEJ architectures remain supported.18:16
khemso we are on the edge now for qemuarm18:16
*** Bunio_FH <Bunio_FH!> has joined #yocto18:17
*** ant_home <ant_home!> has joined #yocto18:19
*** sno <sno!~sno@2a01:598:8187:f519:f1cb:6d15:894b:4c02> has quit IRC18:23
*** dqx <dqx!~dqx@unaffiliated/dqx> has joined #yocto18:23
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC18:28
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto18:28
NeilSok figured out the issue with the u-boot build. A few options were not defined in the defconfig since we have our own defconfig. It's similar to the mx6 with a couple of options changed. I'm guessing the newer version of u-boot needed them. Additioanlly I had to add my new custome config options to the KConfig. Those two steps fixed the u-boot build issue.18:32
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto18:33
no_such_userCan anyone point me at a reference that explains the (git) workflow yocto uses? Im trying to get my head round the relationship between master / master-next / <release> / <release>-next ...18:36
*** WillMiles <WillMiles!> has joined #yocto18:36
*** cquast <cquast!~cquast@> has quit IRC18:41
*** sno <sno!> has joined #yocto18:57
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto18:59
khemRP: it seems it fails sometimes
khemno_such_user: you submit the patch to mailing list and that ends up in master-next or release-next as a staging for maintainers to do some CI and validation, if all goes well it gets into master or release branch whereever its destined for19:07
khemreview also happens on mailing list and if someone has feedback + the results of CI it either goes back to submitter to prepare a new version which addresses the problems or gets accepted if all is ok19:08
*** niro22 <niro22!> has quit IRC19:09
no_such_userkhem: Thanks! Specifically what Im trying to work out, is that I understand that my workflow in my layers should match the yocto workflow, especially to leverage stable release layers. However is (upstream) development just in master/master-next and named release layers *just* bugfixes?19:10
no_such_userand if something is new development, should it be in master and then backported down?19:11
khemyes main development happens on master and we follow a time based release model, where we release on roughly 6months cadence that becomes the release, we branch out and call it some obscure name and move master ahead19:14
khemfrom thereon, release branches only get bug fixes + security fixes and occasionally package upgrades but that is an exception and rarely done19:15
khemusually other layers integrate with release branches and call their branches with same branch name to keep it simple for users19:16
khemand some layers lay ground rules on how far back they support different releases and ensure that single branch keeps working across all those releases19:17
khemsome layers just stick to older releases and skip few releases to sync with later release19:17
khemso there are different release strategies in place that I have seen19:18
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC19:24
*** frsc <frsc!> has quit IRC19:24
*** frsc <frsc!> has joined #yocto19:27
*** rcw <rcw!~rcw@> has quit IRC19:34
*** Bunio_FH <Bunio_FH!> has quit IRC19:34
*** rcw <rcw!~rcw@> has joined #yocto19:35
*** varjag <varjag!> has left #yocto19:46
*** marka <marka!~masselst@> has quit IRC19:47
*** OpenSorceress <OpenSorceress!> has joined #yocto19:54
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto19:54
no_such_userkhem: Ah great that makes sense, thanks19:56
no_such_userkhem: So if my BSP is based on external layers with stable branches e.g. "rocko" I should develop locally with "rocko-next" branch in my layer, keeping my own "rocko" for stable code? i.e. Im basically ignoring master19:57
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC19:59
yoctiNew news from stackoverflow: devtool upgrade ERROR: recipe is already in your workspace <>20:12
*** frsc <frsc!> has quit IRC20:12
*** frsc <frsc!> has joined #yocto20:16
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto20:33
rburtonno_such_user: call your branches whatever you want, that's the policy for the oe branches.  don't follow a next branch though because they'll change and broken stuff might be in there.20:36
no_such_userrburton: Ah, ok thanks. I got the impression from the yocto bsp guide that I should be following the same branching scheme...!20:38
no_such_user(although I think it probably makes sense to do so anyway as reduces complications)20:38
*** tprrt <tprrt!> has joined #yocto20:38
rburtonno_such_user: god no, do what you want20:40
rburtonif you're working on a BSP that is designed to be used with OE the following the naming is pretty obviously the right thing to do20:40
rburtonie call the branch that works with thud "thud"20:40
rburton(do consider tracking master too though, so you're not always a release behind)20:43
no_such_userThanks! (Ive really so far just been looking at what NXP do in their layers and trying to use copying their methodology as a starting point)20:46
neverpanicCan't emphasise the "do consider tracking master" enough. Upgrades are a lot smoother when all the work doesn't have to be done at once.20:47
no_such_userneverpanic: Id love to do that - trouble is ive a whole heap of historic layers Ive inherited that are nowhere near master!20:50
*** rcw <rcw!~rcw@> has quit IRC20:54
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC20:57
*** marka <marka!~masselst@> has joined #yocto21:03
*** rcw <rcw!~rcw@> has joined #yocto21:12
*** rcw <rcw!~rcw@> has quit IRC21:22
*** rcw <rcw!~rcw@> has joined #yocto21:22
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC21:24
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto21:24
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC21:35
NeilSHey i'm trying to use poppler with my qt5 app and it keeps saying poppler-qt5.h not found when I do the bitbake build of my app21:37
NeilSpoppler built.. I have libpoppler-dev installed21:38
*** rcw <rcw!~rcw@> has quit IRC21:39
*** rcw <rcw!~rcw@> has joined #yocto21:40
*** WillMiles <WillMiles!> has quit IRC21:44
*** OpenSorceress <OpenSorceress!> has joined #yocto21:45
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto21:45
rburtonNeilS: maybe you need to turn on qt5 support in the poppler recipe?21:52
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC21:55
*** rcw <rcw!~rcw@> has quit IRC21:58
*** rburton <rburton!> has quit IRC22:00
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto22:29
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC22:36
khemif you add meta-qt5 layer to your layermix then it should automatically enable qt5 support in poppler atleast on the version in master22:42
NeilSi do have meta-qt522:44
NeilSinfact i'm building with meta-boot2qt22:44
*** OpenSorceress <OpenSorceress!> has joined #yocto22:45
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto22:45
NeilSagain something that built with krogoth, builds with sumo but my qt5 app doesn't build22:45
*** gaulishcoin <gaulishcoin!> has quit IRC22:46
NeilSi add this to the .bbappend to try it.22:46
NeilSEXTRA_OECONF += "-DENABLE_QT5=ON"  DEPENDS += "qtbase qttools-native"22:46
NeilSwould this be correct to enable qt5 support ?22:47
*** kaspter <kaspter!~Instantbi@> has quit IRC22:53
*** kaspter <kaspter!~Instantbi@> has joined #yocto22:54
*** marka <marka!~masselst@> has quit IRC22:54
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC22:55
NeilSso maybe the path is wrong if the lib or header are now in a different place where should I look for them22:56
NeilSin the work dir?22:56
khemyeah find them in recipe-sysroot22:56
NeilSthanks for your help.. will poke more at this tmrw22:59
*** yates <yates!> has quit IRC23:08
RPkhem: more likely a race somewhere :/23:26
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto23:26
RPkhem: I ran glibc 2.29 through the AB pre the toolchain changes and we were fine. I can run it again with them at some point over the next few days23:26
*** av <av!~Mutter@> has joined #yocto23:27
*** av <av!~Mutter@> has quit IRC23:34

Generated by 2.11.0 by Marius Gedminas - find it at!