Thursday, 2019-05-16

*** vineela <vineela!vtummala@nat/intel/x-zbwtyqtaboujryar> has quit IRC00:09
*** armpit <armpit!~armpit@2601:202:4180:c33:95b6:a51b:ec63:2621> has joined #yocto00:11
*** samlman <samlman!ca8e31c2@gateway/web/freenode/ip.> has joined #yocto00:38
samlmanAfter 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@> has joined #yocto01:18
*** samlman <samlman!ca8e31c2@gateway/web/freenode/ip.> has quit IRC01:29
*** camus <camus!~Instantbi@> has joined #yocto02:44
*** kaspter <kaspter!~Instantbi@> has quit IRC02:46
*** camus is now known as kaspter02:46
*** fatalhalt <fatalhalt!> has quit IRC03:01
*** kaspter <kaspter!~Instantbi@> has quit IRC03:34
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:34
*** dv_ <dv_!~dv@> has quit IRC04:00
*** dv_ <dv_!> has joined #yocto04:15
*** agust <agust!> has joined #yocto05:08
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC05:11
*** AndersD <AndersD!> has joined #yocto05:25
*** AndersD <AndersD!> has quit IRC05:29
*** AndersD <AndersD!> has joined #yocto05:31
*** Bunio_FH <Bunio_FH!> has joined #yocto05:31
*** cvasilak <cvasilak!~cvasilak@2a02:587:8110:4000:1431:6b90:cc8a:e4d6> has joined #yocto06:19
*** frsc <frsc!> has joined #yocto06:26
*** TobSnyder <TobSnyder!> has joined #yocto06:35
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC06:43
*** jmiehe <jmiehe!> has joined #yocto06:45
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto06:46
*** nslu2-log <nslu2-log!~nslu2-log@> has joined #yocto06:54
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC07:01
*** tprrt <tprrt!~tprrt@> has joined #yocto07:01
*** kroon <kroon!~kroon@> has joined #yocto07:14
*** kroon <kroon!~kroon@> has joined #yocto07:18
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:19
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:24
ernstpwhat clean commands do people use? I often do rm -rf tmp/ because it never has issues and is pretty fast on my computer07:26
LetoThe2ndernstp: depends on what i want to archieve07:26
*** nayfe <nayfe!uid259604@gateway/web/> has joined #yocto07:27
ernstpI 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 IRC07:29
ernstpI saw rm -rf tmp/work/ suggested by someone, is that picked up correctly by the buildsystem?07:29
LetoThe2ndernstp: well *why* are you cleaning? what do you want to archieve07:29
ernstpright! my Jenkins server right now nukes the whole tmp/, to be able to handle any kind of change07:31
*** yacar_ <yacar_!~yacar@> has joined #yocto07:31
ernstpbut it's on the slow side so parsing recipes and setting up tools takes a lot of time every time07:32
ernstpso I was thinking if there was something in between that was a good compromise07:32
ernstpthere's also tmp/stamps/ that's interesting...07:32
kroonernstp, have you seen rm_work.bbclass ?07:34
ernstpkroon: interesting... is that to save disk space mostly or?07:36
kroonernstp, yes07:37
kroonernstp, it wipes most of the build artefacts after a recipe build, but keeps log files around07:38
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto07:40
LetoThe2ndernstp: 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 rebuilds07:41
LetoThe2ndernstp: 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
ernstpLetoThe2nd: you mean nuke tmp and save sstate? yes, and that's pretty close to what I want07:42
LetoThe2ndernstp: nuking tmp and saving sstate exercises image creating, but no source rebuilds.07:42
ernstpLetoThe2nd: but let's say there's one recipe that's been updated07:43
*** Hodhr <Hodhr!> has left #yocto07:43
ernstpLetoThe2nd: then you need to setup the native sysroot and the sysroot, from sstate. and that takes some time on a slow computer07:43
ernstpall the setscene stuff...07:47
LetoThe2ndernstp: 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 #yocto07:50
ernstpLetoThe2nd: somewhat of a microoptimization yes... just incredibly starved on HW at the moment07:50
ernstpnuking tmp/ is extremely stable, so that's nice.07:51
LetoThe2ndernstp: consider spinning up cloud instances :)07:51
ernstpno matter what kindof silly patches people throw at it...07:51
ernstpLetoThe2nd: 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 #yocto07:58
*** frsc <frsc!> has quit IRC08:00
*** frsc <frsc!> has joined #yocto08:00
mcfriskhmm, are patches which reduce GPLv3 dependecies ok for poky?08:01
mcfriskfor example dropping GNU readline support from sqlite3?08:01
fraythey have been fine in the past..08:02
mcfriskthis kind of changes don't fit to meta-gplv2 either08:02
mcfriskcould there be gplv3 distro feature which could be disabled?08:02
fraythere 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
frayIf 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
mcfriskah, so I could create readline PKGCONFIG setting and disable RDEPENDS based on that08:03
frayif 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 layer08:04
mcfriskcurrently meta-gplv2 provides old readline version so the changes don't fit there either..08:04
mcfriskthen again the bbappends to drop readline dependency in sqlite3, lua etc are really trivial for me now08:05
frayeven 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
frayya, dropping readline dependencies belong in the originating layer in my opinion.  This isn't a GPLv* issue, but a general dependency thing08:06
frayare you just dropping it, or replacing it with something like editline?08:06
mcfriskatm just dropping it.08:06
frayok.. ya, that makes sense for a PACKAGECONFIG switch to me08:06
*** Crofton <Crofton!> has quit IRC08:12
*** falstaff <falstaff!~quassel@> has quit IRC08:18
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:32
*** florian_kc is now known as florian08:33
RPmcfrisk: adding a PACKAGECONFIG for it certainly should be fine08:33
RPmcfrisk: we could then put an example set of PACKAGECONFIGs into meta-gplv208:33
*** khem <khem!~khem@unaffiliated/khem> has quit IRC08:34
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto08:36
*** yacar_ <yacar_!~yacar@> has quit IRC08:42
*** yacar_ <yacar_!~yacar@> has joined #yocto08:42
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:48
*** fl0v0 <fl0v0!> has joined #yocto09:25
*** lfa <lfa!~lfa@> has joined #yocto09:28
fl0v0Is 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 independent09:28
fl0v0LetoThe2nd: 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 package09:33
LetoThe2ndfl0v0: exacty. sounds like you want to split the recipe.09:33
*** TafThorne1 <TafThorne1!~thomas@> has joined #yocto09:44
*** grumble <grumble!~^$@freenode/staff/grumble> has quit IRC09:52
*** leitao <leitao!~leitao@2620:10d:c092:200::1:52a4> has quit IRC09:56
*** grumble <grumble!~grumble@freenode/staff/grumble> has joined #yocto09:58
*** mckoan|away is now known as mckoan10:02
*** khem <khem!~khem@unaffiliated/khem> has quit IRC10:14
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto10:17
*** yacar_ <yacar_!~yacar@> has quit IRC10:23
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto10:33
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC10:37
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto10:40
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC10:55
*** xtron <xtron!~xtron@> has quit IRC10:59
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto11:00
*** kanavin <kanavin!~kanavin@> has joined #yocto11:22
kanavinRP: is DL_DIR safe to share over r/w NFS? I couldn't find a definitive answer.11:23
RPkanavin: yes11:23
RPkanavin: the autobuilder does it11:23
JaMais there some documentation about what is published in ? and how (e.g. from which builds)?11:26
*** berton <berton!~berton@> has joined #yocto11:26
kanavinRP: thanks. I thought the autobuilder fetches things separately prior to starting the builds?11:27
*** berton <berton!~berton@> has quit IRC11:28
*** berton <berton!~berton@> has joined #yocto11:30
*** cvasilak <cvasilak!~cvasilak@2a02:587:8110:4000:1431:6b90:cc8a:e4d6> has quit IRC11:32
RPkanavin: it once did, these days it only does a sanity check on what is there :/11:37
*** comptroller <comptroller!> has quit IRC11:39
*** comptroller <comptroller!> has joined #yocto11:44
fraythe big issue with any sharing over NFS is that many NFS servers and clients are 'slightly broken'.  So replacing files causes issues..11:47
frayif you can do the file replacement in an atomic fashion, that usually resolves the problem except on the really broken systems11:48
JaMadoesn't bitbake fetcher locks handle that well enough?11:48
frayno.. because locking doesn't always work on NFS fileservers.. :P11:49
fraycause NFS is usually slightly broken11:49
fraynone of this is anything wrong with OE/bitbake..  it's all due to NFS itself being horribly broken..11:49
frayusually result is failures reading files (as they're being written to by other sessions)11:50
JaMathe 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
frayi.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 client11:50
frayI 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@> has left #yocto11:50
* JaMa surprised that RHEL 5.6 isn't broken enough for us to see this :)11:51
fraybut 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 issues11:51
RPfray: 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 cases11:52
JaMabut 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
frayya, like I said.. the problem is NOT OE/bitbake.. the rpoblem is 100% in the NFS servers and clients11:52
fraythey're just plain broken in many cases11:52
*** radsquirrel <radsquirrel!> has quit IRC11:53
frayfor 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 FYI11:54
JaMaand then you share that local download cache with PREMIRROR?11:55
fray(we also disable external network acccess on those builders)11:55
*** radsquirrel <radsquirrel!> has joined #yocto11:55
fraylimits it to one controlled environment that accesses outside network resources.. helped us control network traffic when a major upgrade happened11:56
JaMaok, makes sense, the only downside I see is that all the builders are blocked until this separate process is done updating all needed pieces11:56
fraycorrect.. but you can run that process in parallel with the regular builds, since it's addative11:57
JaMawhich might not be big issue for you if you don't need so many updates11:57
frayjust 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
JaManot 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 that11:58
*** berton_ <berton_!~berton@> has joined #yocto11:58
frayya that is different then us..11:58
frayfor 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
JaMawith 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 time11:59
frayonce 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 IRC11:59
JaMaand the shared DL_DIR is then used by developers in given location as local PREMIRROR as well11:59
*** berton <berton!~berton@> has quit IRC12:00
*** kroon <kroon!~kroon@> has quit IRC12:02
*** bradleyb <bradleyb!> has joined #yocto12:02
JaMafor 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!> has quit IRC12:02
*** yacar_ <yacar_!~yacar@> has joined #yocto12:03
*** kroon <kroon!~kroon@> has joined #yocto12:04
JaMaand 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
frayYa 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
kanavinhopefully the task queue will be rewritten to consider cache after every step instead of only once at the beginning12:08
frayand 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
fraykanavin 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
JaMakanavin: that would be nice especially with the sstate equivalence thing which would compare the build output of each step12:10
frayabout 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
JaMagood 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
kanavinfray, may I ask whome are you visiting, or is that ultra secret? I lived in Helsinki for 15 years12:13
fraythink large telco company.. :)  headquartered in Espoo12:13
kanavinworked for Nokia, then Intel12:13
frayya this is the training facility to the west12:14
kanavinin Helsinki area anything outside of the smallish core center feels like middle of nowhere, it's basically an overgrown village12:15
*** bradleyb <bradleyb!> has quit IRC12:23
*** radsquirrel <radsquirrel!> has joined #yocto12:24
*** frsc <frsc!> has quit IRC12:30
*** TafThorne1 <TafThorne1!~thomas@> has left #yocto12:34
*** justanotherboy <justanotherboy!> has joined #yocto12:50
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto12:53
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC12:54
*** frsc <frsc!> has joined #yocto12:55
yoctiNew news from stackoverflow: 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 #yocto13:22
*** kroon <kroon!~kroon@> has quit IRC13:30
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC13:38
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto13:41
*** comptroller <comptroller!> has quit IRC13:45
*** kaspter <kaspter!~Instantbi@> has quit IRC13:48
*** kaspter <kaspter!~Instantbi@> has joined #yocto13:50
*** lexano <lexano!~lexano@> has quit IRC13:50
*** kroon <kroon!~kroon@> has joined #yocto13:52
*** AndersD <AndersD!> has quit IRC13:55
*** comptroller <comptroller!> has joined #yocto13:59
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC14:01
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto14:02
*** lexano <lexano!~lexano@> has joined #yocto14:03
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC14:06
*** vineela <vineela!~vtummala@> has joined #yocto14:15
*** tijko <tijko!~tijko@unaffiliated/tijko> has joined #yocto14:15
*** justanotherboy <justanotherboy!> has quit IRC14:17
*** justanotherboy <justanotherboy!> has joined #yocto14:17
*** TobSnyder <TobSnyder!> has quit IRC14:21
*** comptroller <comptroller!> has quit IRC14:22
*** kroon <kroon!~kroon@> has quit IRC14:22
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto14:22
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC14:25
*** dreyna <dreyna!> has joined #yocto14:26
*** elvispre <elvispre!> has joined #yocto14:31
*** Bunio_FH <Bunio_FH!> has quit IRC14:35
*** comptroller <comptroller!> has joined #yocto14:36
*** rcw <rcw!~rcw@> has joined #yocto14:39
*** vineela <vineela!~vtummala@> has quit IRC14:41
*** aehs29 <aehs29!~aehs29@> has quit IRC14:56
*** yacar_ <yacar_!~yacar@> has quit IRC15:00
JaMaRP: khem: it looks like there is still some missing PREFERRED_VERSION for one of gcc recipes (maybe only with multilib enabled)15:00
JaMaglibc just failed for me with: 9.1.0/ld.bfd: cannot find -lgcc while using the current default GCCVERSION ?= "8.%"15:01
JaMaNOTE: recipe lib32-gcc-cross-arm-9.1.0-r0: task do_populate_lic_setscene: Started15:01
JaMaNOTE: recipe lib32-gcc-runtime-8.3.0-r0: task do_populate_lic_setscene: Started15:01
JaMaNOTE: recipe gcc-cross-canadian-aarch64-8.3.0-r0: task do_populate_lic_setscene: Succeeded15:02
JaMaNOTE: recipe gcc-cross-canadian-arm-9.1.0-r0: task do_populate_lic_setscene: Started15:02
JaMait's set only for cross-${TARGET_ARCH}/cross-canadian-${TRANSLATED_TARGET_ARCH} not the other arch from multilib15:03
JaMamaybe using negative D_P while the newest one isn't the default one would make sense as well15:04
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto15:05
*** yacar_ <yacar_!~yacar@> has joined #yocto15:15
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC15:15
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto15:17
*** kroon <kroon!~kroon@> has joined #yocto15:18
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC15:20
*** tprrt <tprrt!~tprrt@> has quit IRC15:21
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto15:23
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC15:25
alessioigorThe do_image_complete function removes the old images. Is there a way to avoid this (that is keep the old images)?  Thanks!15:27
RPJaMa: I wonder why we don't see that on our multlib tests. I kind of left this fuzzy to track down some of these issues15:30
RPJaMa: I did think I had them all after sorting fortran though15:31
RPwell, there is a better way to sort fortran but...15:31
JaMaRP: is there build log from one of multilib builds on AB? maybe it also builds 2 different versions, just without triggering the failure in glibc15:35
JaMaI'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
RPJaMa: you're probably right about it working and not triggering the failure15:38
RPJaMa: had a quick grep over the step*b logs and can't see gcc 9 anywhere15:40
JaManeither did I, will try to replicate the multilib setup from AB and compare the debug output from multilib_global.bbclass15:41
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto15:42
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC15:46
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto15:47
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC15:51
*** yacar_ <yacar_!~yacar@> has quit IRC16:00
*** rcw <rcw!~rcw@> has quit IRC16:01
*** rcw <rcw!~rcw@> has joined #yocto16:02
*** fl0v0 <fl0v0!> has quit IRC16:05
*** Bunio_FH <Bunio_FH!> has joined #yocto16:08
*** kroon <kroon!~kroon@> has quit IRC16:12
*** jofr <jofr!> has joined #yocto16:14
*** learningc <learningc!~learningc@> has joined #yocto16:24
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:31
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC16:37
*** jmiehe <jmiehe!> has quit IRC16:37
*** noway96 <noway96!> has joined #yocto16:39
*** mrpelotazo <mrpelotazo!> has joined #yocto16:40
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto16:43
JaMamultilib magic continues ERROR: Nothing PROVIDES 'lib32-gcc-cross-i586'. Close matches: lib32-gcc-cross-i686 lib32-go-cross-i586 lib32-gdb-cross-i68616:46
JaMaand 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-i68616:48
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has joined #yocto16:49
*** mckoan is now known as mckoan|away16:49
JaMaah, that's proabably because go-cross sets PN = "go-cross-${TUNE_PKGARCH}" and PREFERRED_VERSION_go-cross-${TARGET_ARCH}16:52
*** rcw <rcw!~rcw@> has quit IRC16:52
*** rcw <rcw!~rcw@> has joined #yocto16:52
alessioigorIs there a way to create more than an image(wic) from same recipe(bb)?16:59
*** tprrt <tprrt!> has joined #yocto17:02
*** noway96 <noway96!> has quit IRC17:02
RPJaMa: ah, that starts to explain more about what is going on17:02
*** Crofton <Crofton!> has joined #yocto17:03
*** learningc <learningc!~learningc@> has quit IRC17:04
JaMaRP: 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 similarly17:05
JaMaI've sent RFC about go-cross (in case someone remembers why TUNE_PKGARCH is used there)17:06
kanavinRP: I took a look at bitbake/lib/bb/ yeah it's not easy :) there are two separate executor classes for setscene tasks and 'real' tasks, first one runs to completion then the other17:12
kanavinthe rewrite would have to somehow combine both into one mega-loop, where each completed real task would trigger another pass at setscene tasks17:13
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:17
JPEWkanavin: That was my conclusion also17:23
*** nate02 <nate02!> has joined #yocto17:23
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto17:24
*** kaspter <kaspter!~Instantbi@> has quit IRC17:41
*** kaspter <kaspter!~Instantbi@> has joined #yocto17:41
*** aehs29 <aehs29!~aehs29@> has joined #yocto17:44
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:54
erakisHi, 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
JPEWerakis: I think bitbake only imports a small number of variable from the environment17:58
kanavinerakis, environment variables are generally a very difficult thing to debug, I would recommend you control your recipe behaviour through other means17:59
JPEWerakis: But, you want to be careful about doing that because it can cause a lot of unecessary rebuilding17:59
kanavinIf I had a time machine, I would prevent them from happening at all.18:00
erakisSuppose 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
erakiskanavin: What do you propose?18:04
erakisJPEW: Thank you.18:05
*** lfa_ <lfa_!~lfa@> has joined #yocto18:05
kanavinerakis, where would you use the job id?18:06
kanavinif you want to include it in images' filenames, you can rename them after bitbake completes18:07
*** lfa <lfa!~lfa@> has quit IRC18:09
erakiskanavin: 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 is18:12
erakisway I though passing the job id using an environment variable was a good idea.18:12
*** tijko <tijko!~tijko@unaffiliated/tijko> has quit IRC18:13
JPEWerakis: 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:
JaMaerakis: FWIW we're using BB_ENV_WHITELIST exacly for this to pass BUILD_ID from jenkins to bitbake environment18:17
JaMawhich is then used to construct consistent versioning of all build artifacts (images, kernel images, modules, etc)18:18
kanavinthe 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 point18:18
kanavinfor this reason I always prefer passing data via files18:18
JaMafor us they are e.g. written at the beggining of build in the Build Configuration, so it's quite clear what they were18:19
JaMaunlike some files which most people cannot ever access on the build slaves filesystem18:19
*** leitao <leitao!~leitao@2620:10d:c092:200::1:5db8> has quit IRC18:20
kanavinfiles however remain in place after something has failed, so you can go and inspect them18:20
kanavinfor environment vars, you have to insert printouts at strategic points in code18:21
erakisWhat 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
erakisafter which the variable is available in the recipes.18:21
JaManot 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 script18:21
*** chandana73 <chandana73!~ckalluri@> has joined #yocto18:22
kanavinJaMa, 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
kanavinI 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
kanavinhad it passed configuration via a file, it'd be far easier to deduce18:23
JaMaas long as you don't export that BB_ENV_WHITELISTed variable, then what's wrong with that?18:24
*** yann <yann!> has joined #yocto18:27
erakiskanavin: JaMa: Thank you for you advise.18:29
*** dreyna <dreyna!> has quit IRC18:36
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto18:42
*** jofr <jofr!> has quit IRC18:44
*** Bunio_FH <Bunio_FH!> has quit IRC18:44
JaMaRP: the multilib/gcc P_V issue is really strange, if I add another localdata.expand(v) before then it works for my aarch64 (with arm multilib) case as well, will dig a bit more18:47
*** marble_visions <marble_visions!~user@> has quit IRC18:56
*** marble_visions <marble_visions!~user@> has joined #yocto18:57
*** kroon <kroon!> has joined #yocto19:06
*** rcw <rcw!~rcw@> has quit IRC19:10
*** rcw <rcw!~rcw@> has joined #yocto19:10
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC19:19
*** chandana73 <chandana73!~ckalluri@> has quit IRC19:21
RPJaMa: that does seem odd :/19:21
RPkanavin: your summary is correct, it is basically a rewrite of runqueue :/19:22
RPkanavin: still thinking about that packagegroup rebuild thing19:23
RPkanavin: I worry 7298 is related and it'd be the second time that bug has come up recently19:24
*** rcw <rcw!~rcw@> has quit IRC19:25
*** lfa_ <lfa_!~lfa@> has quit IRC19:30
*** yizhao <yizhao!~zhaoyi@> has quit IRC19:32
*** yizhao <yizhao!~zhaoyi@> has joined #yocto19:36
kanavinRP: 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.> has joined #yocto19:44
armpitRP you still awake ?19:51
armpitbug 10653 is in Stephen's name19:51
yoctiBug normal, Medium, Future,, NEW , Improve Node.js developer workflow.19:51
* armpit thats freaky19:53
*** chandana73 <chandana73!~ckalluri@> has joined #yocto20:04
*** kroon <kroon!> has quit IRC20:05
*** rcw <rcw!~rcw@> has joined #yocto20:11
*** dreyna <dreyna!> has joined #yocto20:12
*** rcw <rcw!~rcw@> has quit IRC20:20
*** rcw <rcw!~rcw@> has joined #yocto20:20
psrcodeIs 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 #yocto20:22
psrcodeeasily that is20:25
kergothworst case just use _remove.20:28
*** rcw <rcw!~rcw@> has quit IRC20:29
RParmpit: yes, kind of20:30
RPpsrcode: 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
psrcodekergoth: that could actually do it, not sure why I did not think about thatr20:32
psrcodeRP: yep, will look at it. I should be able to reproduce this with a simple conf with lttng-tools-ptest installed?20:33
RPpsrcode: yes, its a core-image-minimal with lttng-tools-ptest and openssh added (plus some space and memory for qemu)20:33
psrcodeRP: what tree are you testing this against? juste to be sure I have the same tree20:33
RPpsrcode: basically the exact config lines in my email. It was with current master20:34
psrcodei'll give it a try20:34
RPpsrcode: 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
psrcodekergoth: will the _remove be scoped to only the current recipe?20:35
kergothif it's defined in the recipe or bbappend, then by definition yes, a recipe can't affect configuration or other recipe metadata20:36
kergothotherwise use the _pn- override20:36
psrcodekergoth: 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@> has joined #yocto20:46
*** tprrt <tprrt!> has quit IRC20:49
JaMaRP: 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@> has quit IRC20:51
*** rcw <rcw!~rcw@> has joined #yocto20:51
JaMaRP: 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!> has quit IRC20:54
*** rcw <rcw!~rcw@> has quit IRC20:57
JaMaRP: after replacing _append with .= it works as well21:00
*** ant_home <ant_home!> has joined #yocto21:02
*** mbittan <mbittan!513954bf@gateway/web/freenode/ip.> has quit IRC21:05
*** dreyna <dreyna!> has quit IRC21:05
* armpit wonders if overrides is shooting?21:08
*** justanotherboy <justanotherboy!> has quit IRC21:08
*** justanotherboy <justanotherboy!~justanoth@> has joined #yocto21:09
* armpit or maybe overrides is German21:09
*** juvenal <juvenal!Elite21271@gateway/shell/elitebnc/x-xzwbzkepstukpopi> has quit IRC21:10
JaMashooting Germans?21:11
*** berton_ <berton_!~berton@> has quit IRC21:11
*** juvenal <juvenal!Elite21271@gateway/shell/elitebnc/x-ngrbwmgnrudnhewe> has joined #yocto21:13
*** likewise <likewise!> has quit IRC21:17
JPEWErr, whats the Upstream-Status for an unmaintaned project (zip)?21:31
*** JaMa <JaMa!> has quit IRC21:35
yoctiNew news from stackoverflow: Unable to parse Machine ?= raspberrypi? <>21:51
*** agust <agust!> has quit IRC21:52
*** justanotherboy <justanotherboy!~justanoth@> has quit IRC22:12
yoctiNew news from stackoverflow: How To Determine Which Recipe Built A File In The Target SDK? <>22:21
armpitJPEW, Inappropriate [dead project] ?22:26
armpitah,, nope22:27
armpitno upstream (the upstream is no longer available -- dead project)22:27
armpitits in
yoctiNew news from stackoverflow: How to tell bitbake to calculate variable's basehash value after specific task? <>22:51
*** stephano <stephano!stephano@nat/intel/x-ejnpckhgfudyrlwc> has joined #yocto22:53
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC23:14
*** ant_home <ant_home!> has quit IRC23:20
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto23:21

Generated by 2.11.0 by Marius Gedminas - find it at!