| *** vineela <vineela!vtummala@nat/intel/x-zbwtyqtaboujryar> has quit IRC | 00:09 | |
| *** armpit <armpit!~armpit@2601:202:4180:c33:95b6:a51b:ec63:2621> has joined #yocto | 00:11 | |
| *** samlman <samlman!ca8e31c2@gateway/web/freenode/ip.202.142.49.194> has joined #yocto | 00:38 | |
| samlman | After adding 'tools-sdk tools-debug' to EXTRA_IMAGE_FEATURES I can no longer login to my board with root/nopassword.. am I doing something wrong? | 00:39 |
|---|---|---|
| *** kaspter <kaspter!~Instantbi@183.156.65.21> has joined #yocto | 01:18 | |
| *** samlman <samlman!ca8e31c2@gateway/web/freenode/ip.202.142.49.194> has quit IRC | 01:29 | |
| *** camus <camus!~Instantbi@183.156.65.21> has joined #yocto | 02:44 | |
| *** kaspter <kaspter!~Instantbi@183.156.65.21> has quit IRC | 02:46 | |
| *** camus is now known as kaspter | 02:46 | |
| *** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC | 03:01 | |
| *** kaspter <kaspter!~Instantbi@183.156.65.21> has quit IRC | 03:34 | |
| *** kaspter <kaspter!~Instantbi@183.156.65.21> has joined #yocto | 03:34 | |
| *** dv_ <dv_!~dv@62.178.50.190> has quit IRC | 04:00 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 04:15 | |
| *** agust <agust!~agust@p508B6FD6.dip0.t-ipconnect.de> has joined #yocto | 05:08 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-znahcuwgotyjgfua> has quit IRC | 05:11 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:25 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 05:29 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:31 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 05:31 | |
| *** cvasilak <cvasilak!~cvasilak@2a02:587:8110:4000:1431:6b90:cc8a:e4d6> has joined #yocto | 06:19 | |
| *** frsc <frsc!~frsc@200116b824f237002d851804fd604764.dip.versatel-1u1.de> has joined #yocto | 06:26 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 06:35 | |
| *** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has quit IRC | 06:43 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 06:45 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 06:46 | |
| *** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has joined #yocto | 06:54 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 07:01 | |
| *** tprrt <tprrt!~tprrt@217.114.201.133> has joined #yocto | 07:01 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 07:14 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 07:18 | |
| *** alessioigor <alessioigor!~alessioig@140.105.207.227> has joined #yocto | 07:19 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:24 | |
| ernstp | what clean commands do people use? I often do rm -rf tmp/ because it never has issues and is pretty fast on my computer | 07:26 |
| LetoThe2nd | ernstp: depends on what i want to archieve | 07:26 |
| *** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-dctqxasbabnnlakp> has joined #yocto | 07:27 | |
| ernstp | I know deleting tmp/deploy/ can lead to issues because the recipies don't expect that... | 07:27 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 07:29 | |
| ernstp | I saw rm -rf tmp/work/ suggested by someone, is that picked up correctly by the buildsystem? | 07:29 |
| LetoThe2nd | ernstp: well *why* are you cleaning? what do you want to archieve | 07:29 |
| ernstp | right! my Jenkins server right now nukes the whole tmp/, to be able to handle any kind of change | 07:31 |
| *** yacar_ <yacar_!~yacar@80.215.198.248> has joined #yocto | 07:31 | |
| ernstp | but it's on the slow side so parsing recipes and setting up tools takes a lot of time every time | 07:32 |
| ernstp | so I was thinking if there was something in between that was a good compromise | 07:32 |
| ernstp | there's also tmp/stamps/ that's interesting... | 07:32 |
| kroon | ernstp, have you seen rm_work.bbclass ? | 07:34 |
| ernstp | kroon: interesting... is that to save disk space mostly or? | 07:36 |
| kroon | ernstp, yes | 07:37 |
| kroon | ernstp, it wipes most of the build artefacts after a recipe build, but keeps log files around | 07:38 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 07:40 | |
| LetoThe2nd | ernstp: the point is, what do you want to test? if you nuke tmp including sstate, then a new rerun actually will probably just exercise the signatures and image creation, but no source rebuilds | 07:41 |
| LetoThe2nd | ernstp: so if you want to make sure your ci exercises rebuilds of your applications, you either have to wipe sstate (globally), or bitbake -c cleansstate $YOURRECIPE (specifically) | 07:42 |
| ernstp | LetoThe2nd: you mean nuke tmp and save sstate? yes, and that's pretty close to what I want | 07:42 |
| LetoThe2nd | ernstp: nuking tmp and saving sstate exercises image creating, but no source rebuilds. | 07:42 |
| ernstp | LetoThe2nd: but let's say there's one recipe that's been updated | 07:43 |
| *** Hodhr <Hodhr!~Hodhr@162.206.70.37.rev.sfr.net> has left #yocto | 07:43 | |
| ernstp | LetoThe2nd: then you need to setup the native sysroot and the sysroot, from sstate. and that takes some time on a slow computer | 07:43 |
| ernstp | all the setscene stuff... | 07:47 |
| LetoThe2nd | ernstp: i would maybe agree in a dev workflow, but on a ci system? those are basically meant to check your work asynchronously anyways. | 07:49 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 07:50 | |
| ernstp | LetoThe2nd: somewhat of a microoptimization yes... just incredibly starved on HW at the moment | 07:50 |
| ernstp | nuking tmp/ is extremely stable, so that's nice. | 07:51 |
| LetoThe2nd | ernstp: consider spinning up cloud instances :) | 07:51 |
| ernstp | no matter what kindof silly patches people throw at it... | 07:51 |
| ernstp | LetoThe2nd: I've heard about this cloud :-) | 07:52 |
| ernstp | "rm -rf tmp/stamps/" runs all the setscene like "rm -rf tmp/" but your recipe parsing cache seems to not be invalidated... | 07:55 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:52a4> has joined #yocto | 07:58 | |
| *** frsc <frsc!~frsc@200116b824f237002d851804fd604764.dip.versatel-1u1.de> has quit IRC | 08:00 | |
| *** frsc <frsc!~frsc@i59F4BDE3.versanet.de> has joined #yocto | 08:00 | |
| mcfrisk | hmm, are patches which reduce GPLv3 dependecies ok for poky? | 08:01 |
| mcfrisk | for example dropping GNU readline support from sqlite3? | 08:01 |
| fray | they have been fine in the past.. | 08:02 |
| mcfrisk | this kind of changes don't fit to meta-gplv2 either | 08:02 |
| mcfrisk | could there be gplv3 distro feature which could be disabled? | 08:02 |
| fray | there is a meta-gplv2 repository that may be used for some of these things, but in the main oe-core -- usually we want this implemented as an optional PKGCONFIG/PACKAGECONFIG setting.. | 08:02 |
| fray | If there were a gplv3 distro feature, it should be implemented in the meta-gplv2 layer IMHO. The general OE community is not interested in a GPLv3 limited or free system. However they are interested in reducing dependencies (or alternative dependencies) | 08:03 |
| mcfrisk | ah, so I could create readline PKGCONFIG setting and disable RDEPENDS based on that | 08:03 |
| fray | yes | 08:03 |
| fray | if reducing / changing dependencies meets your goals -- then I'd say oe-core. If it's specifically just reducing dependency on GPLv3, then it likely belongs in the meta-gplv2 layer | 08:04 |
| mcfrisk | currently meta-gplv2 provides old readline version so the changes don't fit there either.. | 08:04 |
| mcfrisk | then again the bbappends to drop readline dependency in sqlite3, lua etc are really trivial for me now | 08:05 |
| fray | even in that case, linking against readline is something that is frowned upon -- since it introduced a GPL 'library'. (vs LGPL). So that dependency drop is reasonable in any of the layers in my opinion.. | 08:05 |
| fray | ya, dropping readline dependencies belong in the originating layer in my opinion. This isn't a GPLv* issue, but a general dependency thing | 08:06 |
| fray | are you just dropping it, or replacing it with something like editline? | 08:06 |
| mcfrisk | atm just dropping it. | 08:06 |
| fray | ok.. ya, that makes sense for a PACKAGECONFIG switch to me | 08:06 |
| *** Crofton <Crofton!~Crofton@mingus.hcro.org> has quit IRC | 08:12 | |
| *** falstaff <falstaff!~quassel@37.17.239.109> has quit IRC | 08:18 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 08:32 | |
| *** florian_kc is now known as florian | 08:33 | |
| RP | mcfrisk: adding a PACKAGECONFIG for it certainly should be fine | 08:33 |
| RP | mcfrisk: we could then put an example set of PACKAGECONFIGs into meta-gplv2 | 08:33 |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 08:34 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 08:36 | |
| *** yacar_ <yacar_!~yacar@80.215.198.248> has quit IRC | 08:42 | |
| *** yacar_ <yacar_!~yacar@80.215.198.248> has joined #yocto | 08:42 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:48 | |
| *** fl0v0 <fl0v0!~fvo@i5E869009.versanet.de> has joined #yocto | 09:25 | |
| *** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 09:28 | |
| fl0v0 | Is there an easy way to mark a package as machine independent? The recipe has one package that includes a file depending on the machine, but the other package it produces is completely independent | 09:28 |
| LetoThe2nd | fl0v0: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-allarch | 09:29 |
| fl0v0 | LetoThe2nd: the allarch class makes the whole recipe architecure independent if I understood correctly, but i just want to make one package machine independent. Maybe i have to create a own recipe then for the dependent package | 09:33 |
| LetoThe2nd | fl0v0: exacty. sounds like you want to split the recipe. | 09:33 |
| *** TafThorne1 <TafThorne1!~thomas@95.130.100.149> has joined #yocto | 09:44 | |
| *** grumble <grumble!~^$@freenode/staff/grumble> has quit IRC | 09:52 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:52a4> has quit IRC | 09:56 | |
| *** grumble <grumble!~grumble@freenode/staff/grumble> has joined #yocto | 09:58 | |
| *** mckoan|away is now known as mckoan | 10:02 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 10:14 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 10:17 | |
| *** yacar_ <yacar_!~yacar@80.215.198.248> has quit IRC | 10:23 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 10:33 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 10:37 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 10:40 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 10:55 | |
| *** xtron <xtron!~xtron@110.93.212.98> has quit IRC | 10:59 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 11:00 | |
| *** kanavin <kanavin!~kanavin@62.96.135.139> has joined #yocto | 11:22 | |
| kanavin | RP: is DL_DIR safe to share over r/w NFS? I couldn't find a definitive answer. | 11:23 |
| RP | kanavin: yes | 11:23 |
| RP | kanavin: the autobuilder does it | 11:23 |
| JaMa | is there some documentation about what is published in http://sstate.yoctoproject.org/ ? and how (e.g. from which builds)? | 11:26 |
| *** berton <berton!~berton@181.220.86.53> has joined #yocto | 11:26 | |
| kanavin | RP: thanks. I thought the autobuilder fetches things separately prior to starting the builds? | 11:27 |
| *** berton <berton!~berton@181.220.86.53> has quit IRC | 11:28 | |
| *** berton <berton!~berton@181.220.86.53> has joined #yocto | 11:30 | |
| *** cvasilak <cvasilak!~cvasilak@2a02:587:8110:4000:1431:6b90:cc8a:e4d6> has quit IRC | 11:32 | |
| RP | kanavin: it once did, these days it only does a sanity check on what is there :/ | 11:37 |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 11:39 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 11:44 | |
| fray | the big issue with any sharing over NFS is that many NFS servers and clients are 'slightly broken'. So replacing files causes issues.. | 11:47 |
| fray | if you can do the file replacement in an atomic fashion, that usually resolves the problem except on the really broken systems | 11:48 |
| JaMa | doesn't bitbake fetcher locks handle that well enough? | 11:48 |
| fray | no.. because locking doesn't always work on NFS fileservers.. :P | 11:49 |
| fray | cause NFS is usually slightly broken | 11:49 |
| fray | none of this is anything wrong with OE/bitbake.. it's all due to NFS itself being horribly broken.. | 11:49 |
| fray | usually result is failures reading files (as they're being written to by other sessions) | 11:50 |
| JaMa | the only issue I've seen related to this in last 6+ years (with 20+ builders sharing NFS from quite old RHEL) is when the lock file wasn't removed when bitbake was forcibly killed at wrong moment (happended about 3 times) | 11:50 |
| fray | i.e. you start reading a file.. the file then changes and the NFS server pukes and you get the equivalent of an I/O error on the original client | 11:50 |
| fray | I have customers who see this all the time.. much of the time they are use netapps and such to serve NFS to Linux clients.. | 11:50 |
| *** prabhakarlad <prabhakarlad!~prabhakar@194.75.40.178> has left #yocto | 11:50 | |
| * JaMa surprised that RHEL 5.6 isn't broken enough for us to see this :) | 11:51 | |
| fray | but I've even seen it Linux client to Linux client.. IF they have problems with this kind of things, I always recommend moving to an rsync 'push', with an http pull for mirrors... takes more local space, but seems to resolve the issues | 11:51 |
| RP | fray: we're quite careful about not changing files unless we have locks so file issues tend not to be a problem. We assume the locking works well enough for our use cases | 11:52 |
| JaMa | but also re-downloads the same thing many times when multiple builders are triggered for the same change at the same time (our typical scenario) | 11:52 |
| fray | ya, like I said.. the problem is NOT OE/bitbake.. the rpoblem is 100% in the NFS servers and clients | 11:52 |
| fray | they're just plain broken in many cases | 11:52 |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 11:53 | |
| fray | for our builders we have dedicated processes that fetch from the network.. all of the other build process then only fetch from the local download cache.. that avoids the multiple builders trying to fetch the same thing issue (and ensures our local cache is always complete) | 11:53 |
| fray | --runall=fetch FYI | 11:54 |
| JaMa | and then you share that local download cache with PREMIRROR? | 11:55 |
| fray | yes | 11:55 |
| fray | (we also disable external network acccess on those builders) | 11:55 |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 11:55 | |
| fray | limits it to one controlled environment that accesses outside network resources.. helped us control network traffic when a major upgrade happened | 11:56 |
| JaMa | ok, makes sense, the only downside I see is that all the builders are blocked until this separate process is done updating all needed pieces | 11:56 |
| fray | correct.. but you can run that process in parallel with the regular builds, since it's addative | 11:57 |
| JaMa | which might not be big issue for you if you don't need so many updates | 11:57 |
| fray | just have to make sure you do the download fetch before running a series of builds.. in our environment we have ways to do this -- but due to the volume of builds, there may be short periods of time that the featcher hasnt caught up.. but these are generally "quick" failures.. | 11:58 |
| JaMa | not in the way how we're using it, we have a developer which creates a review in gerrit somewhere and might trigger CI in completely different location few minutes after that | 11:58 |
| *** berton_ <berton_!~berton@181.220.86.53> has joined #yocto | 11:58 | |
| fray | ya that is different then us.. | 11:58 |
| fray | for those types of builds we start with the premirror from the fetch resource, and then allow network access for the rest.. but that 'rest' is not cached, since the change hasn't been comitted to the repository yet.. | 11:59 |
| JaMa | with shared DL_DIR first builder which gets to do_fetch, downloads new reference from remote location to local NFS in shared DL_DIR, other builders if they reach do_fetch as well, will wait a bit until the lock is lifted and then they finish all at almost the same time | 11:59 |
| fray | once it's committed hten the regular process kicks off and actually stores the download longer term.. | 11:59 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 11:59 | |
| JaMa | and the shared DL_DIR is then used by developers in given location as local PREMIRROR as well | 11:59 |
| *** berton <berton!~berton@181.220.86.53> has quit IRC | 12:00 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 12:02 | |
| *** bradleyb <bradleyb!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 12:02 | |
| JaMa | for the committed changes it's the same for us, someone will create annotated submissions/NN tag in the repository somewhere and almost immediately trigger verification build with metadata change incrementing the submission number for his component. | 12:02 |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 12:02 | |
| *** yacar_ <yacar_!~yacar@80.215.198.248> has joined #yocto | 12:03 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 12:04 | |
| JaMa | and the same with shared SSTATE_DIR, except that the builds started in parallel cannot take much advantage of one of them finishing the task a bit sooner (because the setscene tasks were already finished and they all already decided to run the actual task itself) | 12:05 |
| fray | Ya the shared SSTATE_DIR, I'm not sure how exactly that is setup... the build guys have figured it out, but I know at one point rsync was involved to ensure atomic updates... not sure fi it's still being used.. but NFS was a real problem and we got away from it as far as R/W, and moved to read-only.. | 12:08 |
| kanavin | hopefully the task queue will be rewritten to consider cache after every step instead of only once at the beginning | 12:08 |
| fray | and every time we chased down a problem, it was a bug in the NFS server itself.. OE was doing the right thing already.. | 12:08 |
| fray | kanavin that is really the only deficiency I see with the current way of doing things.. (other then initial parse performance, but we've looked at that and I'm not sure it can be optimized any further without a possibly radical change) | 12:09 |
| JaMa | kanavin: that would be nice especially with the sstate equivalence thing which would compare the build output of each step | 12:10 |
| fray | about to give an "intro to yocto" presentation to folks who were formerly application engineers and never had to deal with recipes or running the build system.. :) | 12:11 |
| JaMa | good luck! :) | 12:11 |
| fray | (biggest trick will be to get a taxi when I'm done with this back to Helsinki.. I'm some 35 minutes west of Helsinki right now.. kind of the middle of nowhere) :) | 12:12 |
| kanavin | fray, may I ask whome are you visiting, or is that ultra secret? I lived in Helsinki for 15 years | 12:13 |
| fray | think large telco company.. :) headquartered in Espoo | 12:13 |
| kanavin | worked for Nokia, then Intel | 12:13 |
| fray | ya this is the training facility to the west | 12:14 |
| kanavin | in Helsinki area anything outside of the smallish core center feels like middle of nowhere, it's basically an overgrown village | 12:15 |
| *** bradleyb <bradleyb!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 12:23 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 12:24 | |
| *** frsc <frsc!~frsc@i59F4BDE3.versanet.de> has quit IRC | 12:30 | |
| *** TafThorne1 <TafThorne1!~thomas@95.130.100.149> has left #yocto | 12:34 | |
| *** justanotherboy <justanotherboy!~justanoth@THOUSAND-EY.bear1.Houston1.Level3.net> has joined #yocto | 12:50 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 12:53 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 12:54 | |
| *** frsc <frsc!~frsc@200116b824f237009bda169ec8c544e1.dip.versatel-1u1.de> has joined #yocto | 12:55 | |
| yocti | New news from stackoverflow: How to build a customized linux kernel image for sama5d27 som1 ek1 board? <https://stackoverflow.com/questions/56169585/how-to-build-a-customized-linux-kernel-image-for-sama5d27-som1-ek1-board> | 13:19 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 13:22 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 13:30 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 13:38 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 13:41 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 13:45 | |
| *** kaspter <kaspter!~Instantbi@183.156.65.21> has quit IRC | 13:48 | |
| *** kaspter <kaspter!~Instantbi@183.156.65.21> has joined #yocto | 13:50 | |
| *** lexano <lexano!~lexano@66.133.76.51> has quit IRC | 13:50 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 13:52 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 13:55 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 13:59 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 14:01 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 14:02 | |
| *** lexano <lexano!~lexano@66.133.76.51> has joined #yocto | 14:03 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 14:06 | |
| *** vineela <vineela!~vtummala@134.134.139.74> has joined #yocto | 14:15 | |
| *** tijko <tijko!~tijko@unaffiliated/tijko> has joined #yocto | 14:15 | |
| *** justanotherboy <justanotherboy!~justanoth@THOUSAND-EY.bear1.Houston1.Level3.net> has quit IRC | 14:17 | |
| *** justanotherboy <justanotherboy!~justanoth@THOUSAND-EY.bear1.Houston1.Level3.net> has joined #yocto | 14:17 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 14:21 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 14:22 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 14:22 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 14:22 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 14:25 | |
| *** dreyna <dreyna!~dreyna@24-113-124-115.wavecable.com> has joined #yocto | 14:26 | |
| *** elvispre <elvispre!~elvispre@ftp.och.me.uk> has joined #yocto | 14:31 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 14:35 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 14:36 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 14:39 | |
| *** vineela <vineela!~vtummala@134.134.139.74> has quit IRC | 14:41 | |
| *** aehs29 <aehs29!~aehs29@149.199.62.129> has quit IRC | 14:56 | |
| *** yacar_ <yacar_!~yacar@80.215.198.248> has quit IRC | 15:00 | |
| JaMa | RP: khem: it looks like there is still some missing PREFERRED_VERSION for one of gcc recipes (maybe only with multilib enabled) | 15:00 |
| JaMa | glibc just failed for me with: 9.1.0/ld.bfd: cannot find -lgcc while using the current default GCCVERSION ?= "8.%" | 15:01 |
| JaMa | NOTE: recipe lib32-gcc-cross-arm-9.1.0-r0: task do_populate_lic_setscene: Started | 15:01 |
| JaMa | NOTE: recipe lib32-gcc-runtime-8.3.0-r0: task do_populate_lic_setscene: Started | 15:01 |
| JaMa | NOTE: recipe gcc-cross-canadian-aarch64-8.3.0-r0: task do_populate_lic_setscene: Succeeded | 15:02 |
| JaMa | NOTE: recipe gcc-cross-canadian-arm-9.1.0-r0: task do_populate_lic_setscene: Started | 15:02 |
| JaMa | it's set only for cross-${TARGET_ARCH}/cross-canadian-${TRANSLATED_TARGET_ARCH} not the other arch from multilib | 15:03 |
| JaMa | maybe using negative D_P while the newest one isn't the default one would make sense as well | 15:04 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 15:05 | |
| *** yacar_ <yacar_!~yacar@80.215.198.248> has joined #yocto | 15:15 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 15:15 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 15:17 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 15:18 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 15:20 | |
| *** tprrt <tprrt!~tprrt@217.114.201.133> has quit IRC | 15:21 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 15:23 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 15:25 | |
| alessioigor | The do_image_complete function removes the old images. Is there a way to avoid this (that is keep the old images)? Thanks! | 15:27 |
| RP | JaMa: I wonder why we don't see that on our multlib tests. I kind of left this fuzzy to track down some of these issues | 15:30 |
| RP | JaMa: I did think I had them all after sorting fortran though | 15:31 |
| RP | well, there is a better way to sort fortran but... | 15:31 |
| JaMa | RP: is there build log from one of multilib builds on AB? maybe it also builds 2 different versions, just without triggering the failure in glibc | 15:35 |
| RP | JaMa: https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/611 | 15:36 |
| JaMa | I'm debugging the code in multilib_global.bbclass and I'm not seeing TARGET_ARCH to be expanded with multilib (only the MLPREFIX added) | 15:36 |
| RP | JaMa: you're probably right about it working and not triggering the failure | 15:38 |
| RP | JaMa: had a quick grep over the step*b logs and can't see gcc 9 anywhere | 15:40 |
| JaMa | neither did I, will try to replicate the multilib setup from AB and compare the debug output from multilib_global.bbclass | 15:41 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 15:42 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 15:46 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 15:47 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 15:51 | |
| *** yacar_ <yacar_!~yacar@80.215.198.248> has quit IRC | 16:00 | |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 16:01 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 16:02 | |
| *** fl0v0 <fl0v0!~fvo@i5E869009.versanet.de> has quit IRC | 16:05 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 16:08 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 16:12 | |
| *** jofr <jofr!~jof@90.184.86.154.1.fullrate.ninja> has joined #yocto | 16:14 | |
| *** learningc <learningc!~learningc@121.121.98.128> has joined #yocto | 16:24 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:31 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:37 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 16:37 | |
| *** noway96 <noway96!~noway96@50-244-213-195-static.hfc.comcastbusiness.net> has joined #yocto | 16:39 | |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-078-042-004-194.hsi3.kabel-badenwuerttemberg.de> has joined #yocto | 16:40 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 16:43 | |
| JaMa | multilib magic continues ERROR: Nothing PROVIDES 'lib32-gcc-cross-i586'. Close matches: lib32-gcc-cross-i686 lib32-go-cross-i586 lib32-gdb-cross-i686 | 16:46 |
| JaMa | and I don't mean the i586 in lib32-gcc-cross-i586 I've used in bitbake -e, but go-cross is using i586 arch, while P_V is set only for lib32-go-cross-i686 | 16:48 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto | 16:49 | |
| *** mckoan is now known as mckoan|away | 16:49 | |
| JaMa | ah, that's proabably because go-cross sets PN = "go-cross-${TUNE_PKGARCH}" and PREFERRED_VERSION_go-cross-${TARGET_ARCH} | 16:52 |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 16:52 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 16:52 | |
| alessioigor | Is there a way to create more than an image(wic) from same recipe(bb)? | 16:59 |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto | 17:02 | |
| *** noway96 <noway96!~noway96@50-244-213-195-static.hfc.comcastbusiness.net> has quit IRC | 17:02 | |
| RP | JaMa: ah, that starts to explain more about what is going on | 17:02 |
| *** Crofton <Crofton!~Crofton@mingus.hcro.org> has joined #yocto | 17:03 | |
| *** learningc <learningc!~learningc@121.121.98.128> has quit IRC | 17:04 | |
| JaMa | RP: but this only on go-cross (not gcc-cross), so it might be separate issue, in my build it seems to work for x86_64 (and i686 multilib), but not aarch64 (and arm multilib) with multilib enabled in both machines very similarly | 17:05 |
| JaMa | I've sent RFC about go-cross (in case someone remembers why TUNE_PKGARCH is used there) | 17:06 |
| kanavin | RP: I took a look at bitbake/lib/bb/runqueue.py... yeah it's not easy :) there are two separate executor classes for setscene tasks and 'real' tasks, first one runs to completion then the other | 17:12 |
| kanavin | the rewrite would have to somehow combine both into one mega-loop, where each completed real task would trigger another pass at setscene tasks | 17:13 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 17:17 | |
| JPEW | kanavin: That was my conclusion also | 17:23 |
| *** nate02 <nate02!~nate02@mail.validmanufacturing.com> has joined #yocto | 17:23 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 17:24 | |
| *** kaspter <kaspter!~Instantbi@183.156.65.21> has quit IRC | 17:41 | |
| *** kaspter <kaspter!~Instantbi@183.156.65.21> has joined #yocto | 17:41 | |
| *** aehs29 <aehs29!~aehs29@149.199.62.129> has joined #yocto | 17:44 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 17:54 | |
| erakis | Hi, it's probably a dumb question but if I call `bitbake` by setting first an environment variable `MY_VAR=1 && bitbake image`. How can I read the value of MY_VAR from the recipe ? xx = ${MY_VAR} ? | 17:55 |
| JPEW | erakis: I think bitbake only imports a small number of variable from the environment | 17:58 |
| JPEW | erakis: https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#var-bb-BB_ENV_WHITELIST | 17:58 |
| kanavin | erakis, environment variables are generally a very difficult thing to debug, I would recommend you control your recipe behaviour through other means | 17:59 |
| JPEW | erakis: But, you want to be careful about doing that because it can cause a lot of unecessary rebuilding | 17:59 |
| kanavin | If I had a time machine, I would prevent them from happening at all. | 18:00 |
| erakis | Suppose I want to launch a build from a CD/DI system like Gitlab. I would like to pass the job/build ID to yocto and retrieved it from a recipe. The only way I found so far is to declare a variable into the `local.conf` and then lunch the bitbake from a script that use `sed ....` to replace the variable's value by the one coming from an environment variable or the script's parameters. | 18:03 |
| erakis | kanavin: What do you propose? | 18:04 |
| erakis | JPEW: Thank you. | 18:05 |
| *** lfa_ <lfa_!~lfa@217.19.35.51> has joined #yocto | 18:05 | |
| kanavin | erakis, where would you use the job id? | 18:06 |
| kanavin | if you want to include it in images' filenames, you can rename them after bitbake completes | 18:07 |
| *** lfa <lfa!~lfa@217.19.35.51> has quit IRC | 18:09 | |
| erakis | kanavin: The job id is automatically generated on Gitlab when build is triggered via web api or web interface. We use it as a build id. But once the image is build and flash on the device we have no way to read the original build number. I recently discovered the recipe `distro-feed-configs` and then I would override it to include the gitlab job id in the `/etc/build` file. When gilab runner trigger a build it open a shell and then launch bitbake so this is | 18:12 |
| erakis | way I though passing the job id using an environment variable was a good idea. | 18:12 |
| *** tijko <tijko!~tijko@unaffiliated/tijko> has quit IRC | 18:13 | |
| JPEW | erakis: bitbake will respect an auto.conf file in addition to local.conf. The auto.conf file is designed to be written by CI. I think if you make your CI job write out this as auto.conf it will do what you want: https://pastebin.com/JxdELz6s | 18:15 |
| JaMa | erakis: FWIW we're using BB_ENV_WHITELIST exacly for this to pass BUILD_ID from jenkins to bitbake environment | 18:17 |
| JaMa | which is then used to construct consistent versioning of all build artifacts (images, kernel images, modules, etc) | 18:18 |
| kanavin | the problem with environment variables is that they live in memory, so when things go wrong, it's difficult to establish what they were at any given point | 18:18 |
| kanavin | for this reason I always prefer passing data via files | 18:18 |
| JaMa | for us they are e.g. written at the beggining of build in the Build Configuration, so it's quite clear what they were | 18:19 |
| JaMa | unlike some files which most people cannot ever access on the build slaves filesystem | 18:19 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC | 18:20 | |
| kanavin | files however remain in place after something has failed, so you can go and inspect them | 18:20 |
| kanavin | for environment vars, you have to insert printouts at strategic points in code | 18:21 |
| erakis | What I'm doing is not far from this, I use a script to start the build. This script open the file `local.conf` and overwrite the value of the variable `MY_BUILD_NUMBER` for `MY_BUILD_NUMBER=4434`. | 18:21 |
| erakis | after which the variable is available in the recipes. | 18:21 |
| JaMa | not for us, when something fails then there is probably many builds in queue which will happily remove all the left-over files and start their own script | 18:21 |
| *** chandana73 <chandana73!~ckalluri@149.199.62.131> has joined #yocto | 18:22 | |
| kanavin | JaMa, that's for debugging failures locally. I know from experience that env vars are a pain in the butt. Just the other day I wanted to upgrade apt in yocto (because the one we have has a major security hole). | 18:22 |
| kanavin | I decided to do something else after finding out the new apt sanitizes the environment, and I have no idea where to start looking for where it happens. | 18:23 |
| kanavin | had it passed configuration via a file, it'd be far easier to deduce | 18:23 |
| JaMa | as long as you don't export that BB_ENV_WHITELISTed variable, then what's wrong with that? | 18:24 |
| *** yann <yann!~yann@lfbn-1-3372-5.w90-127.abo.wanadoo.fr> has joined #yocto | 18:27 | |
| erakis | kanavin: JaMa: Thank you for you advise. | 18:29 |
| *** dreyna <dreyna!~dreyna@24-113-124-115.wavecable.com> has quit IRC | 18:36 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 18:42 | |
| *** jofr <jofr!~jof@90.184.86.154.1.fullrate.ninja> has quit IRC | 18:44 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 18:44 | |
| JaMa | RP: the multilib/gcc P_V issue is really strange, if I add another localdata.expand(v) before http://git.openembedded.org/openembedded-core/tree/meta/classes/multilib_global.bbclass#n38 then it works for my aarch64 (with arm multilib) case as well, will dig a bit more | 18:47 |
| *** marble_visions <marble_visions!~user@68.183.79.8> has quit IRC | 18:56 | |
| *** marble_visions <marble_visions!~user@68.183.79.8> has joined #yocto | 18:57 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 19:06 | |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 19:10 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 19:10 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 19:19 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.131> has quit IRC | 19:21 | |
| RP | JaMa: that does seem odd :/ | 19:21 |
| RP | kanavin: your summary is correct, it is basically a rewrite of runqueue :/ | 19:22 |
| RP | kanavin: still thinking about that packagegroup rebuild thing | 19:23 |
| RP | kanavin: I worry 7298 is related and it'd be the second time that bug has come up recently | 19:24 |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 19:25 | |
| *** lfa_ <lfa_!~lfa@217.19.35.51> has quit IRC | 19:30 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 19:32 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 19:36 | |
| kanavin | RP: this however is pretty clear-cut special case - the packagegroup explicitly refers to packages with TUNE_ARCH in their name (smth like binutils-cross-canadian-$TUNE_ARCH). If TUNE_ARCH changes, packagegroup must be rebuilt. | 19:40 |
| *** mbittan <mbittan!513954bf@gateway/web/freenode/ip.81.57.84.191> has joined #yocto | 19:44 | |
| armpit | RP you still awake ? | 19:51 |
| armpit | bug 10653 is in Stephen's name | 19:51 |
| yocti | Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=10653 normal, Medium, Future, sjolley.yp.pm, NEW , Improve Node.js developer workflow. | 19:51 |
| * armpit thats freaky | 19:53 | |
| *** chandana73 <chandana73!~ckalluri@149.199.62.131> has joined #yocto | 20:04 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC | 20:05 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 20:11 | |
| *** dreyna <dreyna!~dreyna@24-113-124-115.wavecable.com> has joined #yocto | 20:12 | |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 20:20 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 20:20 | |
| psrcode | Is there any way to override/modify the CONFIGUREOPTS from autotools? I'm trying to remove the --target and replace it by --enable-targets= for gdb-cross, it is mostly to access the threaddb functionnality of gdb (a big hack). | 20:21 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 20:22 | |
| psrcode | easily that is | 20:25 |
| kergoth | worst case just use _remove. | 20:28 |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 20:29 | |
| RP | armpit: yes, kind of | 20:30 |
| RP | psrcode: not sure if you saw it but I've been testing more ptest configurations and lttng-tools-ptest isn't working so well on a core-image-minimal. I suspect there are some "obvious" dependencies we're missing but its back to the timeouts :/ | 20:32 |
| psrcode | kergoth: that could actually do it, not sure why I did not think about thatr | 20:32 |
| psrcode | RP: yep, will look at it. I should be able to reproduce this with a simple conf with lttng-tools-ptest installed? | 20:33 |
| RP | psrcode: yes, its a core-image-minimal with lttng-tools-ptest and openssh added (plus some space and memory for qemu) | 20:33 |
| psrcode | RP: what tree are you testing this against? juste to be sure I have the same tree | 20:33 |
| RP | psrcode: basically the exact config lines in my email. It was with current master | 20:34 |
| psrcode | perfect | 20:34 |
| psrcode | i'll give it a try | 20:34 |
| RP | psrcode: I'm sure its something obvious missing, I've not looked into what yet as there are a few issues that test highlighted... | 20:35 |
| psrcode | kergoth: will the _remove be scoped to only the current recipe? | 20:35 |
| kergoth | if it's defined in the recipe or bbappend, then by definition yes, a recipe can't affect configuration or other recipe metadata | 20:36 |
| kergoth | otherwise use the _pn- override | 20:36 |
| psrcode | kergoth: good, sorry for those stupid question, I need to find some time to do a proper reading of the manual. | 20:37 |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 20:46 | |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC | 20:49 | |
| JaMa | RP: I found the reason why the multilib_global.bbclass didn't work with our tune files, it's this line: OVERRIDES_append_class-target = "${@bb.utils.contains('TUNE_FEATURES', 'webos-minsize', ':webos-minsize', '', d)}" | 20:50 |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 20:51 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 20:51 | |
| JaMa | RP: so the OVERRIDES used by localdata in multilib_global.bbclass were: "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:forcevariable${@bb.utils.contains('TUNE_FEATURES', 'webos-minsize', ':webos-minsize', '', d)}:virtclass-multilib-lib32" | 20:52 |
| *** frsc <frsc!~frsc@200116b824f237009bda169ec8c544e1.dip.versatel-1u1.de> has quit IRC | 20:54 | |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 20:57 | |
| JaMa | RP: after replacing _append with .= it works as well | 21:00 |
| *** ant_home <ant_home!~ant__@host98-185-dynamic.56-82-r.retail.telecomitalia.it> has joined #yocto | 21:02 | |
| *** mbittan <mbittan!513954bf@gateway/web/freenode/ip.81.57.84.191> has quit IRC | 21:05 | |
| *** dreyna <dreyna!~dreyna@24-113-124-115.wavecable.com> has quit IRC | 21:05 | |
| * armpit wonders if overrides is shooting? | 21:08 | |
| *** justanotherboy <justanotherboy!~justanoth@THOUSAND-EY.bear1.Houston1.Level3.net> has quit IRC | 21:08 | |
| *** justanotherboy <justanotherboy!~justanoth@38.99.27.232> has joined #yocto | 21:09 | |
| * armpit or maybe overrides is German | 21:09 | |
| *** juvenal <juvenal!Elite21271@gateway/shell/elitebnc/x-xzwbzkepstukpopi> has quit IRC | 21:10 | |
| JaMa | shooting Germans? | 21:11 |
| *** berton_ <berton_!~berton@181.220.86.53> has quit IRC | 21:11 | |
| *** juvenal <juvenal!Elite21271@gateway/shell/elitebnc/x-ngrbwmgnrudnhewe> has joined #yocto | 21:13 | |
| *** likewise <likewise!uid442@beta.alwyzon.com> has quit IRC | 21:17 | |
| JPEW | Err, whats the Upstream-Status for an unmaintaned project (zip)? | 21:31 |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 21:35 | |
| yocti | New news from stackoverflow: Unable to parse Machine ?= raspberrypi? <https://stackoverflow.com/questions/56176934/unable-to-parse-machine-raspberrypi> | 21:51 |
| *** agust <agust!~agust@p508B6FD6.dip0.t-ipconnect.de> has quit IRC | 21:52 | |
| *** justanotherboy <justanotherboy!~justanoth@38.99.27.232> has quit IRC | 22:12 | |
| yocti | New news from stackoverflow: How To Determine Which Recipe Built A File In The Target SDK? <https://stackoverflow.com/questions/56177122/how-to-determine-which-recipe-built-a-file-in-the-target-sdk> | 22:21 |
| armpit | JPEW, Inappropriate [dead project] ? | 22:26 |
| armpit | ah,, nope | 22:27 |
| armpit | no upstream (the upstream is no longer available -- dead project) | 22:27 |
| armpit | its in https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines | 22:27 |
| yocti | New news from stackoverflow: How to tell bitbake to calculate variable's basehash value after specific task? <https://stackoverflow.com/questions/55911423/how-to-tell-bitbake-to-calculate-variables-basehash-value-after-specific-task> | 22:51 |
| *** stephano <stephano!stephano@nat/intel/x-ejnpckhgfudyrlwc> has joined #yocto | 22:53 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 23:14 | |
| *** ant_home <ant_home!~ant__@host98-185-dynamic.56-82-r.retail.telecomitalia.it> has quit IRC | 23:20 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-bbrwxstirthtnvtz> has joined #yocto | 23:21 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!