Tuesday, 2019-07-02

*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC00:13
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC01:15
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto02:08
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC02:57
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto02:58
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has joined #yocto03:34
yoctiNew news from stackoverflow: Yocto build for a static library fails with error "No Match Found" <https://stackoverflow.com/questions/56845122/yocto-build-for-a-static-library-fails-with-error-no-match-found>04:12
*** cvasilak <cvasilak!~cvasilak@ppp-94-66-56-96.home.otenet.gr> has joined #yocto04:46
*** agust <agust!~agust@pD95F1DFD.dip0.t-ipconnect.de> has joined #yocto05:04
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto05:11
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC05:13
MarcWeHi, im getting a: error: this statement may fall through [-Werror=implicit-fallthrough=]06:21
*** tprrt <tprrt!~tprrt@> has joined #yocto06:22
MarcWewhen creating the sdk. if i look in the file where te error is happening it is markt as       /* FALLTHROUGH */06:22
*** Hauke <Hauke!~Hauke@hauke-m.de> has quit IRC06:47
*** edgar444 <edgar444!uid214381@gateway/web/irccloud.com/x-etbzpvphkwlaugxs> has joined #yocto06:55
*** fl0v0 <fl0v0!~fvo@i5E8691FF.versanet.de> has joined #yocto06:58
*** Hodhr <Hodhr!~Hodhr@> has left #yocto07:06
qschulzRP: OK, at least I know it's correct, I'm still confused though why it's in this directory but I'm surely missing a lot of info on how everything works for native packages07:12
qschulzRP: now, is there anyway to add a symlink in a native package without having a warning?07:13
qschulz'I'm confused on how I am supposed to add a symlink in a do_install for a native recipe: `ln -s ${bindir} ${D}${bindir}/foo` does not work because ${bindir} resolves to an absolute path and ln -s ${D}${bindir} ${D}${bindir}/foo also does not work because it's also an absolute path and yocto does not want those anymore for native recipes'07:13
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto07:18
erboqschulz: can't you create a relative symlink by moving into e.g. the destination directory and use ln -s . foo ?07:19
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC07:20
erboI guess you don't even have to move there, just "ln -s <relative path to target> <absolute path to link name>"07:21
*** sven^ <sven^!~quassel@unaffiliated/sven/x-8293843> has joined #yocto07:21
erboand the "relative path" is relative to the link name07:21
*** yacar_ <yacar_!~yacar@87-88-176-101.abo.bbox.fr> has joined #yocto07:21
sven^hey. Is there an easy way to fail a recipe when a variable in the environment is not set? Can I just do something like if [[ -z $MYVAr ]]; then return false?07:22
erboso "ln -s ../ ${D}${bindir}/foo" in your case, I think that would work07:22
sven^(I am talking about do_install_append())07:23
qschulzsven^: bb.error?07:27
sven^that's a thing? Nice!07:27
sven^and checking for empty variables in a bash style way is correct? The error output looks like yocto uses the variable name when it is empty07:28
qschulzsven^: could you give a bit more context on what you're trying to achieve? You might be going the wrong way, so better ensure we find a good solution instead of giving you the hackish way :)07:29
*** kaspter <kaspter!~Instantbi@> has quit IRC07:29
qschulzerbo: well... yes? :) I was a bit weirded out using those kind of symlinks.07:30
qschulznow I'm still wondering why such a tree in the image directory of the recipe.07:30
RPqschulz: -r option to ln ?07:30
sven^I have a package taking gitlabs pipeline id from the environment and dumping it in the final image. So I am doing something like export VERSION_BUILD_ID = "${CI_PIPELINE_ID}". When that variable is not set I get strange errors like "No such directory: .../../image-version/1.0-${CI_PIPELINE_ID}/.../... So it seems yocto uses the variable name when the value is empty. I want to check for that case and just fail the build (as a side effect bitbakes07:32
sven^ creates a ton of directories with names like "!=" , "if", "os.path.normpath(d.getVar(......" which is quite ugly07:32
sven^so I want to abort the moment that variable is not set in the environment (which only happens if you manually build an image and forget to set it or if the runner breaks)07:35
erboqschulz: I'm assuming the paths are set up somewhat special so that bitbake can then assemble a per-recipe sysroot more easily07:36
erboqschulz: it won't install into "/path/to/recipe/workdir/sysroot-native" dir, since that's the sysroot-native dir used for building your recipe.07:37
erboer, no that would be recipe-sysroot-native. My bad.07:38
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:38
*** rperier <rperier!~quassel@unaffiliated/bambee> has quit IRC07:44
*** leitao <leitao!~leitao@2620:10d:c092:200::1:2839> has joined #yocto07:48
*** woutervh <woutervh!~woutervh@> has joined #yocto07:50
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:51
*** yacar_ <yacar_!~yacar@87-88-176-101.abo.bbox.fr> has quit IRC07:54
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC07:57
*** kaspter <kaspter!~Instantbi@> has quit IRC07:59
*** yacar_ <yacar_!~yacar@87-88-176-101.abo.bbox.fr> has joined #yocto08:00
*** yacar_ <yacar_!~yacar@87-88-176-101.abo.bbox.fr> has quit IRC08:04
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:05
*** yacar_ <yacar_!~yacar@87-88-176-101.abo.bbox.fr> has joined #yocto08:08
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto08:10
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto08:10
*** Bunio_FH <Bunio_FH!~bunio@2a02:a313:4343:f080:a1ff:438a:108:725f> has joined #yocto08:22
*** leitao <leitao!~leitao@2620:10d:c092:200::1:2839> has quit IRC08:26
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto08:29
*** bluca <bluca!~bluca@> has joined #yocto08:42
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto08:44
qschulzsven^: can't you have this script to retrieve the pipeline id from a class that you inherit in the recipes you need to use it?08:57
qschulzinstead of using environment variables?08:57
MarcWeHi, i managed to solve the issue by editing the sorce files whats best practes to create a patch for the source code08:58
sven^qschulz: uhm.. it's a seperate recipe that does nothing but to dump the env variable to disc. I simply did a if not d.getVar("...", False): bb.abort(...) now in do_fetch_prepend()08:59
sven^seems to be enough for now08:59
qschulzMarcWe: You can use devtool for example. Or you can use git or quilt manually on top of the actual sources. You create the patch and then you add it in a subdirectory on the same level of the recipe (named after the recipe, or "files", ...) and add this one to SRC_URI with "file://" in front09:06
qschulzMarcWe: if you don't "own" the recipe (i.e. coming from an upstream layer), you can use bbappend (and then you need the FILESEXTRAPATHS_prepend := "${THISDIR}/<name of your subdirectory>" in thie bbappend09:07
qschulzsven^: you could also use a python anonymous function09:07
sven^when do those get executed?09:07
sven^maybe I am a bit blind but I have a hard time finding documentation on how stuff like this works09:08
qschulzsven^: and I don't remember if Yocto is tracking all environment variables or not, but you might want to add them to the list of tracked environment variables so that if it changes, the recipe gets rebuilt09:08
qschulzsven^: at parsing time09:08
sven^like how do I use d? When do I use bb.getVar? etc. pp09:08
MarcWeqschulz:  tnx ( its not my layer so it going to be the second option )09:09
*** saraf <saraf!~a_saraf@> has joined #yocto09:12
sven^qschulz: ok, __anonymous is much better, thanks09:16
qschulzMarcWe: also, might be a good idea to send the patch you created to the maintainer of the project (first to the project, second to the layer)09:16
qschulzthey'll thank you :)09:16
qschulzsven^: we use the two BB_ENV_* variables in my company : https://www.yoctoproject.org/docs/2.6/bitbake-user-manual/bitbake-user-manual.html#var-BB_ENV_WHITELIST09:18
qschulzsven^: it might help you, who knows :)09:18
sven^yeah, we are using BB_EXTRA_WHITE09:18
sven^uh, BB_ENV_EXTRAWHITE09:19
*** ak77 <ak77!c12e4b03@> has joined #yocto09:19
ak77what would be best practice for versioning final image ? image is built using multiple repositories each having its revision... + MACHINE ...09:20
ak77ok. MACHINE doesn't play role. but how to embedded version and revision of used repositories ? make same branch on all of them ? tag all of them ?09:21
sven^complicated topic and if you find a good solution, tell me09:22
sven^we are dumping versions in each package using a class that is inherited in each custom project's recipe. In addition to that we dump each layer's git sha to a file09:23
LetoThe2ndak77: use some form of automation that defines all layer revisions together with the variables to be set. we use kas for that.09:24
sven^+ a repo manifest with fixed commits on each included layer in a main repository responsible for builds with tags for RCs and releases09:24
LetoThe2ndak77: so we have one kas configuration file under version control, which essentially folds out into the would tree of the build.09:24
LetoThe2ndsven^: repo is another possibility, of course. i don't know about its capabilities to automate local.conf generation, though.09:25
ak77sven^: tagging and brancing manifest repo crossed our mind, yes.09:25
ak77sven^: I wouldn't generate local.conf, it could be committed per specific builder09:26
sven^LetoThe2nd: in the main repo there are manifests for repo for development, test builds and releases and a set of local.conf templates that will get copied at the start of a build09:26
ak77sven^: ok ok. different manifests in same repo?09:27
ak77LetoThe2nd: will check "kas"09:27
sven^ak77: yeah. you just run repo init? with the url to the manifest you are trying to build09:27
ak77LetoThe2nd: hmm. any link09:27
LetoThe2ndak77: https://pypi.org/project/kas/09:28
sven^so something like repo init -u ssh://git@gitserver/main-build-repo -u develop.xml09:28
LetoThe2ndsven^: sure, what ever works for your usecase/workflow. i don't think there a one size fits all solution at the moment.09:28
sven^LetoThe2nd: indeed. I have done a bit of research on the topic and in the end we wrote like 1k of python to just script what we want to do09:29
LetoThe2ndsven^: :)09:30
sven^I am still very unhappy with it :)09:30
LetoThe2ndsven^: thats why i usually recommend kas, because it cut down our scripting to almost zero. its just mildly complicated if you use their provided docker container and need to pass in additional environmental things, but nothing unherad of too09:31
LetoThe2ndbut of course, YMMV.09:32
sven^I'll have a look at that09:34
LetoThe2ndhave fun!09:35
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-vkhspilxpanxfoqa> has joined #yocto09:36
*** rburton <rburton!~rburton@> has joined #yocto09:40
ak77kas looks ok, repo approach too. in both cases there is a committed file with revisions09:46
LetoThe2ndak77: exactly, thats what its about.09:49
*** yacar_ <yacar_!~yacar@87-88-176-101.abo.bbox.fr> has quit IRC09:51
*** cvasilak <cvasilak!~cvasilak@ppp-94-66-56-96.home.otenet.gr> has quit IRC09:52
*** cvasilak <cvasilak!~cvasilak@ppp-94-66-56-172.home.otenet.gr> has joined #yocto10:03
*** saraf <saraf!~a_saraf@> has quit IRC10:28
*** gaulishcoin <gaulishcoin!~gaulishco@anice-652-1-21-234.w83-201.abo.wanadoo.fr> has joined #yocto10:31
*** cvasilak <cvasilak!~cvasilak@ppp-94-66-56-172.home.otenet.gr> has quit IRC10:33
sven^yeah and make sure not to use AUTOREV anywhere10:38
LetoThe2ndsven^: ++10:51
LetoThe2ndrburton: i am surprised that INTEL is testing INTEL!!!one!!11!eleven! :)10:51
rburtonintel tests IA, WR test the rest10:52
LetoThe2ndrburton: :-)10:52
LetoThe2ndby the way, any ideas what i could talk about next tues on twitch?11:06
*** yacar_ <yacar_!~yacar@87-88-160-22.abo.bbox.fr> has joined #yocto11:06
*** rperier <rperier!~quassel@unaffiliated/bambee> has joined #yocto11:18
sven^you are talking on twitch?11:19
LetoThe2ndsven^: yep11:20
sven^about what?11:20
LetoThe2ndsven^: i do the monthly live coding session, every second tuesday a month at 17:00 europe/berlin time11:21
sven^coding yocto?11:21
RPLetoThe2nd: testing? how easy it is to add tests? using devtool?11:21
LetoThe2ndsven^: https://www.twitch.tv/yocto_project11:22
LetoThe2ndRP: phew. maybe i should stick to topics i actually know something about :)11:22
sven^LetoThe2nd: nice. I'll check it out next tuesday11:22
RPLetoThe2nd: no sense of adventure? :)11:23
ak77yeah, what tools does openembedded/yocto provide for QA11:23
LetoThe2ndRP: i am highly adventurous! sometime i even drink stout. and when i'm in a really crazy mood, even an IPA. happens only every couple of years, though.11:23
RPLetoThe2nd: :D11:24
RPLetoThe2nd: I like stouts, not keen on IPA though11:24
LetoThe2ndRP: same here. but, i'm being adventurous.11:24
RPhard to find decent ones here11:25
sven^LetoThe2nd: the link to the youtube channel is broken11:25
LetoThe2ndi mean, of course i can rebrand it from live coding to live drinking with the yocto project... hmmmm11:25
LetoThe2ndsven^: let me check11:26
LetoThe2ndsven^: works for me11:26
sven^it leads to https://www.twitch.tv/www.youtube.com/user/TheYoctoProject which is not found11:27
sven^"This content is only available if you have a time machine,11:27
LetoThe2ndsven^: for me it likes to https://www.youtube.com/user/TheYoctoProject directly11:28
RPsven^: LetoThe2nd clearly has a time machine11:28
LetoThe2ndcan anybody else have a look, please?11:28
LetoThe2ndRP: in fact i have. https://en.wikipedia.org/wiki/Time_Machine_(Joe_Satriani_album)11:29
RPLetoThe2nd: there are two links. The "Past stream recordings are on the YouTube channel." one is broken11:30
RPLetoThe2nd: Schedule section11:30
LetoThe2ndaaah ok that explains it. lemme fix it.11:30
sven^LetoThe2nd: the link for Yocto Project Lerning Resources is broken, too11:31
LetoThe2ndbut don't expect too much, we're just uploading the old streams to youtube as we speak... hopefully.11:32
sven^well, I am a newbie and have a lot to learn :)11:32
LetoThe2ndok, both fixed11:35
sven^uh, kas is made by siemens? Oo11:36
*** berton <berton!~berton@> has joined #yocto11:37
sven^that kind of makes me not want to use it...11:38
LetoThe2ndsven^: well is that based upon any real evidence, especially of daniel being a bad coder/maintainer? or jsut generic yuge company bashing?11:41
sven^our platform is compatible to several of their products and it has been a pita to work around their horrendous documentation and implementation quirks11:43
LetoThe2ndmakes me guess you come from plc land11:43
sven^it's probably stupid to assume their yocto contributions are as bad as other things they do (that had 30-40 years to feature creep), but it's just a connection I make subconciously11:44
LetoThe2ndsven^: nothing more to say :)11:44
sven^actually I am working on products that should get rid of plcs on the long run, but as for now we have to be compatible :)11:45
qschulzBefore I go crazy in Yocto recipes/internals, I'm asking here. I'm having a build error in the do_rootfs task of two images for two different images. The error message is the following:11:49
qschulzException: FileExistsError: [Errno 17] File exists: 'tmp/sysroots-components/aarch64/glibc-initial/usr/include/complex.h' -> 'tmp/work/foo-machine-poky-linux/foo-image/1.0-r0/recipe-sysroot/usr/include/complex.h'11:51
RPqschulz: glibc-initial shouldn't be being installed there11:51
RPqschulz: also tells me you're using something pre-warrior as we got rid of glibc-initial11:52
qschulzRP: yes, thud 2.6.211:52
RPqschulz: our test builds don't show that so what you've done to trigger it, I don't know11:52
qschulzGMBRKBNBRGJVERGVJEUG, let the whack-a-mole begin then :(11:53
qschulzRP: Sometimes it fails on `tmp/sysroots-components/aarch64/libgcc-initial/usr/lib64/aarch64-poky-linux/8.2.0/crtendS.o`11:54
qschulzthe same reason11:54
RPqschulz: if its the do_rootfs task, have a look at the do_rootfs log file and see why its installing *-initial11:54
RPThere is code specifically not to install -initial11:55
qschulzRP: Direct dependencies are ... glibc-initial:do_populate_sysroot, gcc-cross-initial:do_populate_sysroot, libgcc-initial:do_populate_sysroot12:02
*** khem <khem!~khem@unaffiliated/khem> has quit IRC12:03
RPqschulz: ok, direct dependencies sounds ominous as I don't think it would be12:03
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto12:04
*** yann <yann!~yann@aputeaux-655-1-52-10.w86-195.abo.wanadoo.fr> has quit IRC12:04
qschulzRP: mmmm, most likely the DEPENDS = "u-boot" in the image recipe was not the best idea :) anyway, changed that to EXTRA_IMAGEDEPENDS12:26
RPqschulz: interesting. I wouldn't have expected that to break it but it certainly could12:26
qschulzRP: now I've got the same issue but with libxcrypt and glibc-initial and the crypto.h file12:27
*** luckywho <luckywho!~quassel@> has joined #yocto12:29
RPqschulz: another direct dependency?12:32
qschulzI guess so :/12:34
*** yacar_ <yacar_!~yacar@87-88-160-22.abo.bbox.fr> has quit IRC12:40
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC13:04
JPEWRP: Sorry, I should have made it more clear that those two patches were related13:13
yoctiNew news from stackoverflow: Compiling issue with Boost asio <https://stackoverflow.com/questions/56852929/compiling-issue-with-boost-asio>13:14
*** yacar_ <yacar_!~yacar@87-88-160-22.abo.bbox.fr> has joined #yocto13:14
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC13:28
*** yacar_ <yacar_!~yacar@87-88-160-22.abo.bbox.fr> has quit IRC13:42
*** JPEW <JPEW!cc4da337@> has quit IRC13:48
*** yacar_ <yacar_!~yacar@87-88-160-22.abo.bbox.fr> has joined #yocto13:56
*** woutervh <woutervh!~woutervh@> has quit IRC14:11
*** JPEW <JPEW!cc4da337@> has joined #yocto14:13
*** woutervh <woutervh!~woutervh@> has joined #yocto14:15
*** yann <yann!~yann@> has joined #yocto14:17
RPJPEW: I was thinking it was a test for the existing option, things make sense now!14:29
RPJPEW: hadn't gotten to looking at the bitbake list yet14:29
JPEWRP: np14:29
qschulzRP: making progress.. I discovered that we have a task in the image that depends on another image14:39
qschulzbasically we have an image which builds a fitimage which requires another image (think of an image having a rescue image in it)14:40
qschulz`do_generate_swupdate[depends] += "swupdate-image:do_build"`14:41
qschulzis that the correct way to do it? (one image depending on another one?)14:41
RPqschulz: it should be ok, I could also imagine its possible to cause problems14:43
qschulzRP: weirdly enough, replacing it by do_generate_swupdate[depends] += "swupdate-image:do_image_complete" (do_build by do_image_complete) make the build ok14:46
RPqschulz: that actually makes sense to me...14:47
*** mckoan|away is now known as mckoan14:47
qschulzis there some magic done when you depends on a do_build? (like... installing something in a sysroot :) ?)14:48
mckoanhello, is there any example/doc about the syntax of LAYERDEPENDS ? For example if Y have a meta-custom that needs meta-java.14:48
*** stephano <stephano!stephano@nat/intel/x-ollahcfxagcwtojq> has joined #yocto14:50
mckoanhttps://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#var-bb-LAYERDEPENDS doesn't help much14:50
*** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has joined #yocto14:50
yatesis there a recipe anywhere for busctl, the dbus command line utility?14:51
mckoanLATERDEPENDS_custom = "meta-java" or = "java-layer" or what else?14:51
RPqschulz: do_build has a recrdepends on other tasks which means you injected a lot of tasks into that point in the build14:51
JPEWmckoan: meta-openembedded has some examples: e.g. `LAYERDEPENDS_perl-layer = "core openembedded-layer"`14:52
*** woutervh <woutervh!~woutervh@> has quit IRC14:52
JPEWI beleive the name has to match the name the layer gives itself in it's conf file14:52
*** woutervh <woutervh!~woutervh@> has joined #yocto14:53
armpitYPTM: Armin is on14:53
*** tprrt <tprrt!~tprrt@> has quit IRC14:54
*** vineela <vineela!~vtummala@> has joined #yocto14:56
RParmpit: early! :)14:58
LetoThe2ndon the yocto ml: But I had almost14:59
LetoThe2nda billion of errors and I am so bored14:59
* LetoThe2nd is bored too.15:00
halsteadYPTM: Michael joined Zoom Meeting: https://zoom.us/j/99089271215:00
* armpit oh, someone flashed me15:01
smurrayarmpit: heh, I accidentally clicked the video button15:02
smurrayYPTM: scott is on15:02
*** JPEW75 <JPEW75!cc4da373@> has joined #yocto15:02
*** JPEW75 is now known as JPEW_15:02
JPEW_YPTM: Joshua Watt here15:03
tlwoernerYPTM: tlwoerner here15:03
rburtonJPEW_: top marks for your reproducibility stuff btw15:04
rburton(can't join the call to say that in person)15:04
JPEW_rburton: Thanks!15:04
qschulzRP: I'm confused, I don't really understand what's happening behind the scenes to make it work with do_image_complete and not do_build15:09
qschulzWhy is it trying to install files in the sysroot of my imagea recipe when I depend on imageb.do_build but not when I depend on imagea.do_image_complete /o\15:10
rburtonqschulz: depending on do_image_complete probably is the right thing anyway15:13
qschulzrburton: but now I need to scratch this itch :D15:14
qschulz(and also, I don't like committing things that I don't understand/can't argue, and it's absolutely impossible to me to do a empty commit log since I'm fighting for people to write meaningful ones :) )15:15
halsteadYPTM is concluded.15:22
armpitYPTM: is over15:22
RPqschulz: do a "bitbake imageb -c do_image_complete -g" and look at task-depends.dot, then do the same but with -c build15:22
RPqschulz: you'll see a lot more dependencies. Its those extra dependencies muddying the water for the sysroot generation code15:23
*** JPEW_ <JPEW_!cc4da373@> has quit IRC15:23
mcfriskHi, compiling older meta-freescale etc nxp layers with poky master. looks like devicetree files no longer get symlinks with KERNEL_IMAGETYPE in the names, but kernel still does. Is this intended? need to adapt sdcard image types of meta-freescale to not expect that15:24
RPmcfrisk: not sure, I'd check the commits to see what caused it and whether it was intentional15:24
*** woutervh <woutervh!~woutervh@> has quit IRC15:27
rburtonhuh SRC_URI=http://git.yoctoproject.org/cgit/cgit.cgi/${BPN}/snapshot/${BPN}-${PV}.tar.gz looks *very* wrong15:27
*** vineela <vineela!~vtummala@> has quit IRC15:27
*** vineela <vineela!~vtummala@> has joined #yocto15:27
RPrburton: where is that?15:27
rburtonoh sorry :)15:27
rburtonthe checksum matches now but if we upgrade the server then that can potentially change15:30
RPrburton: indeed15:30
RPrburton: we should ask adelcast about that15:30
mcfriskRP: I see some major changes in meta/classes/kernel-devicetree.bbclass but I can't see how kernel recipes should be adapted.. only this one symlink is missing with path "${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${DTS_BASE_NAME}.dtb", dropping KERNEL_IMAGETYPE seems to be the fix15:30
RPmcfrisk: I've asked for more tests in this area, I don't use dtbs often enough to know what makes sense :(15:31
*** vineela <vineela!~vtummala@> has quit IRC15:32
mcfriskRP: no problem, I found a fix/workaround then.15:33
*** nemik <nemik!49f6c917@c-73-246-201-23.hsd1.il.comcast.net> has joined #yocto15:38
nemikhello. i am curious about people's opinions or recommendations for system update mechanisms that can perform delta updates, to be cost-efficient over cellular networks.15:40
*** Bunio_FH <Bunio_FH!~bunio@2a02:a313:4343:f080:a1ff:438a:108:725f> has quit IRC15:40
nemikhttps://rauc.readthedocs.io/en/latest/advanced.html#creating-casync-bundles looks very interesting, has anyone used it?15:40
tlwoernerRP: wow, scary. i was 100% certain i had sent an email regarding the pigz issue to the list, turns out i hadn't. i wrote notes about it in my notebook, and i mentioned it on IRC. i'll create an email with all the details.15:46
tlwoernerRP: in the meeting i said i was using version 1.0.6. oops.. wrong utility. that's pixz 1.0.6, my machine has pigz 2.3.315:47
RPtlwoerner: that makes much more sense :)15:49
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto15:56
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC15:58
*** yacar_ <yacar_!~yacar@87-88-160-22.abo.bbox.fr> has quit IRC15:59
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto15:59
mckoanJPEW: does this mean that a layer 'meta-openembedded' have to become "openembedded-layer" in LAYERDEPENDS?16:04
mckoanJPEW: I wonder why is not called 'meta-openembedded', that's confusing16:04
kergothtoo late to do much about it now due to LAYERDEPENDS from other layers16:05
mckoankergoth: JPEW: however could we say that the syntax is to replace the prefix 'meta-' wit a postfix '-layer' in the LAYERDEPENDS?16:08
kergothno, plenty of layers do not use a -layer suffix16:09
JPEWmckoan: It is annoying, but you have to just look in the layer.conf for each layer to determine it's name16:09
kergoththere's a lack of consistency there16:09
* armpit or a strong support of inconsistency16:11
mckoanJPEW: sounds clearer now, do you men to refer to BBFILE_COLLECTIONS like in meta-oe is BBFILE_COLLECTIONS += "openembedded-layer"16:12
JPEWmckoan: Correct16:12
RPwe could probably add a provides mechanism and then fix the names16:13
mckoanJPEW: do you mean to refer to the value of BBFILE_COLLECTIONS in the layer I want to depend onto? like in meta-oe is BBFILE_COLLECTIONS += "openembedded-layer"16:14
mckoanoops, sorry the double post16:14
yoctiNew news from stackoverflow: How to Make a FULL Yocto eSDK Sysroot to Do CMake Cross-Compilation? <https://stackoverflow.com/questions/56856272/how-to-make-a-full-yocto-esdk-sysroot-to-do-cmake-cross-compilation> || devtool clones the wrong repository for recipe development <https://stackoverflow.com/questions/56856154/devtool-clones-the-wrong-repository-for-recipe-development>16:14
mckoanJPEW: thank you very much for this clarification16:14
mckoanRP: may I suggest to describe this in the manual?16:15
RPmckoan: I would love someone to explain it to Scott who would update the manual it someone did that16:16
RPJPEW: btw, the bzip upgrade in -next will break mingw16:16
mckoanRP: LOL16:16
*** nemik <nemik!49f6c917@c-73-246-201-23.hsd1.il.comcast.net> has quit IRC16:21
*** fl0v0 <fl0v0!~fvo@i5E8691FF.versanet.de> has quit IRC16:23
RPmckoan: file a bug and explain it, or send scott an email, seriously16:26
*** jarvis-owl <jarvis-owl!~jarvis@39-62-78-N2.customer.vsm.sh> has joined #yocto16:29
*** jarvis-owl <jarvis-owl!~jarvis@39-62-78-N2.customer.vsm.sh> has quit IRC16:34
*** jwessel <jwessel!~jwessel@> has joined #yocto16:38
mckoanRP: ok, as soon as I have some spare time16:39
*** vineela <vineela!vtummala@nat/intel/x-zpnnrcykkujtmplj> has joined #yocto16:39
*** yann <yann!~yann@> has quit IRC16:43
*** mckoan is now known as mckoan|away16:44
*** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has quit IRC16:46
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:54
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC17:03
*** armpit <armpit!~armpit@2601:202:4180:c33:6404:bfa9:90b3:4039> has quit IRC17:10
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has joined #yocto17:11
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:23
*** Hauke <Hauke!~Hauke@hauke-m.de> has joined #yocto18:00
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-vkhspilxpanxfoqa> has quit IRC18:09
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto18:33
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto18:36
*** yizhao <yizhao!~zhaoyi@> has quit IRC18:39
*** yizhao <yizhao!~zhaoyi@> has joined #yocto18:40
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC18:42
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto18:55
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC19:07
*** armpit <armpit!~armpit@> has joined #yocto19:11
blucadoes the bitbake inline conditional support logical 'and'? it's a bit un-googlable unfortunately: "${@['foo', 'bar'][condition]}"19:30
JPEWbluca: It's inline python.... not sure what you mean by "logical and"19:43
blucaah what's in the [ ] is python? interesting19:43
JPEWbluca: Everything between "${@" and "}" is python19:44
blucaright now condition is ['foo' != 'bar'] - I'd like ['foo' != 'bar' && 'foobar' != 'baz']19:44
blucathanks, I'll try with python's keyword19:44
*** edgar444 <edgar444!uid214381@gateway/web/irccloud.com/x-etbzpvphkwlaugxs> has quit IRC20:15
JPEWRP: master-next of meta-mingw has the bzip2 fix20:22
*** ak77 <ak77!c12e4b03@> has quit IRC20:28
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC20:55
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC20:58
RPJPEW: great, that change has been tested so I can merge, I'd best try and do that when we're both around!20:58
JPEWSounds good. I'll be around tomorrow, but then gone till monday21:00
RPJPEW: tell you what, if you're here now... :)21:00
JPEWYa, for another hour21:01
RPJPEW: its in :)21:01
RPJPEW: I guess I could have just merged the branch too now I think about it... :)21:03
JPEWlol, ya probably.21:04
JPEWBlame it on the end of the day21:04
RPJPEW: just been cycling, still to get food :/21:04
JPEWAlright pushed. I upstreamed the patch, so hopefully next update we can just delete the whole thing from meta-mingw21:05
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto21:06
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC21:07
*** berton <berton!~berton@> has quit IRC21:11
RPJPEW: great, particularly now we have a new working upstream! :)21:11
*** stephano <stephano!stephano@nat/intel/x-ollahcfxagcwtojq> has quit IRC21:11
*** stephano <stephano!stephano@nat/intel/x-sjcnphtwmzhchgnn> has joined #yocto21:21
*** agust <agust!~agust@pD95F1DFD.dip0.t-ipconnect.de> has quit IRC21:33
rburtonbluca: the [foo,bar][condition] thing is horrible and please don't use it if you can help it21:53
rburton"foo if condition else bar" is more readable and as you can see, understandable as python :)21:53
rburton[foo,bar][cond] works because its making a list of [foo, bar] and then indexing it by coercing cond to an integer 0 or 121:54
rburtonICK :)21:54
blucarburton: it's an existing recipe, so not up to me :-)22:03
blucabut yes it is not very readable22:04
*** afr0ck <afr0ck!69eb8211@> has joined #yocto22:12
*** gaulishcoin <gaulishcoin!~gaulishco@anice-652-1-21-234.w83-201.abo.wanadoo.fr> has quit IRC22:23
*** JPEW <JPEW!cc4da337@> has quit IRC22:26
*** afr0ck <afr0ck!69eb8211@> has quit IRC22:26
*** bluca <bluca!~bluca@> has quit IRC22:30
yoctiNew news from stackoverflow: Up-to-date recommendations for yocto build host version <https://stackoverflow.com/questions/56860788/up-to-date-recommendations-for-yocto-build-host-version>22:45
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC22:50
*** rburton <rburton!~rburton@> has quit IRC22:53
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC22:58
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto23:03
*** Pharaoh_Atem is now known as Conan_Kudo23:04
*** Conan_Kudo is now known as Pharaoh_Atem23:04
*** vineela <vineela!vtummala@nat/intel/x-zpnnrcykkujtmplj> has quit IRC23:17
*** vineela <vineela!vtummala@nat/intel/x-mpcecfotltbaahkc> has joined #yocto23:19
*** vineela <vineela!vtummala@nat/intel/x-mpcecfotltbaahkc> has quit IRC23:24
*** Pharaoh_Atem is now known as Conan_Kudo23:26
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC23:30
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC23:47

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