**** BEGIN LOGGING AT Thu Jan 10 03:00:02 2019 Jan 10 08:45:15 hello all Jan 10 08:45:45 is there a way to pull known issues list for a particular release for a OE? Jan 10 09:04:17 I need to get a list of all the issues reported in Morty release Jan 10 09:04:27 how can I get the list Jan 10 09:31:21 Noor: bugzilla? Jan 10 09:32:18 rburton: does it allow you search issues for a particular version Jan 10 09:32:28 I did not see that on web Jan 10 09:32:36 there's a version field Jan 10 09:32:50 won't help where a bug in master is also valid in morty, but better than nothing Jan 10 10:10:06 rburton: thanks Jan 10 16:27:12 hi, I am reading the manual sections about OVERRIDES and I fail to understand how it works... MYVAR = "X", MYVAR_foo = "Y", MYVAR_bar = "Z", OVERRIDES = "bar:foo" But how do I define "now I am running 'bar' so use value of MYVAR_bar" ? Jan 10 16:27:31 your configuration sets that Jan 10 16:27:34 from my experiments the MYVAR is always set to whatever I list in the OVERRIDES last Jan 10 16:27:39 order of the overrides, last has priority, is what is selected.. Jan 10 16:27:50 ie MYVAR_class-target Jan 10 16:27:52 so in that example MYVAR_foo has a higher priority the MYVAR_bar Jan 10 16:27:53 or MYVAR_x86 Jan 10 16:28:09 but how do I define "now I am running configuration bar"? Jan 10 16:28:16 you don't set OVERRIDES yourself typically Jan 10 16:28:19 so it knows what to pick? Jan 10 16:28:32 ok maybe I should reach out to what I am tasked to do Jan 10 16:28:43 look at the default overrides for a build.. you want to use an override that automatically changes based on the behavior you are expecting Jan 10 16:29:00 default here for eg m4 is OVERRIDES="linux:x86-64:pn-m4:corei7-64-intel-common:intel-x86-common:intel-corei7-64:poky:class-target:libc-glibc:forcevariable" Jan 10 16:29:08 i.e. one override is ${TARGET_ARCH}.. that lets you select x86-64, arm, etc.. Jan 10 16:29:25 # set /home/ross/Yocto/poky/meta/conf/bitbake.conf:737 Jan 10 16:29:25 # "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:forcevariable" Jan 10 16:29:30 if you read the bitbake -e for that, you can see what it's made up of (as rburton just posted) Jan 10 16:29:35 ^^ Jan 10 16:29:58 yes I was actually doing btibake -e and trying things out but did not get the results I wanted Jan 10 16:30:18 so in the forcevariable case Jan 10 16:30:33 do I somewhere define FORCEVARIABLE="foo" to trigger the "foo" overrides? Jan 10 16:30:37 no Jan 10 16:30:46 or do I need to add ${FORCEVARIABLE} to overrides? Jan 10 16:30:49 thats the part I dont get Jan 10 16:30:53 how do I trigger my custom stuff? Jan 10 16:30:56 FOO_forcevariable is basically a really ugly hack Jan 10 16:30:58 the default order of the overrides is specifically that way so that target OS has the lowest prescidence, followed by the overall architecture, followed by the recipe itself, followed by specific machine (BSP) items, followed by distribution, then class, and libc.. Jan 10 16:31:10 if you absolute HAVE to override no matter what then: VAR_forcevariable works.. Jan 10 16:31:14 since it's the highest priority override Jan 10 16:31:38 as rburton said, this is a hack.. you should never use forcevariable in a recipe -- or the recipe is wrong Jan 10 16:31:47 rule of thumb: you don't want to extend OVERRIDES Jan 10 16:31:49 rburton: no big deal, but it looks like your latest oe-core patches are from poky repository (have the "From OE-Core rev" .. lines) Jan 10 16:31:50 ok let me get back to the thing I actually need to accomplish, maybe I am approacing this from the wrong side Jan 10 16:31:52 if you do, you're doing it wrong Jan 10 16:32:46 we have several "feeds" for our product, testing, fieldtest, production, currently each feed is an own layer and things get merged further from layer to layer when they become production ready, and the binary build is separate for each layer Jan 10 16:33:42 now they found that its too complicated to merge stuff from layer to layer, so I am told to come up put everything in one layer and come up with a variable that would allow to configure this layer at build time to be either testing/fieldtest/production etc,i.e. each recipe that has differences would need to check that and behave accordingly Jan 10 16:34:04 at the same time its desired to keep _append_machine overrides because some things are additionally machine dependant Jan 10 16:34:16 I was investigating if I could accomplish that configuration definition with overrides Jan 10 16:34:19 so I c Jan 10 16:34:30 so I could use do_install_append_fieldtest() in the recipes Jan 10 16:35:34 am I on the wrong trail with overrides? or would that be a possibility to implement this? Jan 10 16:43:25 guys? Jan 10 16:49:40 You should not modify upstream layers for local work, unless absolutely necessary... If the layers you are merging are internal (to your org) layers, then you can manage it however you want... Jan 10 16:50:14 but best practice really is to have a general 'stable' layer, with each level out (development, testng, etc) having their own local modifications and then merging the patches back to the stable when they themselves are considered to be stable. Jan 10 16:51:07 its our internal layer and we had those internal layers separate, more or less the way you describe, just merging further when considered stable Jan 10 16:51:19 typically the way you would handle a merged layer though is use distro overrides. production and devel/debug would be essentionally different configurations and you could define overrides as such.. but there is a big downside to this. The devel/debug uses a different configuration then production, so this can always introduce difficult to identify bugs Jan 10 16:51:54 now its "too much effort" and all should be one just configurable blah heh ;) but I got a bit further, actually adding ${FEED} to overrides allows me to do FEED = "testing" and then use MYVAR_testing Jan 10 16:52:27 I personally think we'll end up in a total mess and configuration nightmare, but its not my call Jan 10 16:54:40 yes, you will Jan 10 16:54:50 that would be a distro override.. Jan 10 16:55:04 in your layer, you would do something like: Jan 10 16:55:30 DISTROOVERRIDE .= ":${FEED}" Jan 10 16:56:04 but it would not mess up the default poky overrides? Jan 10 16:56:14 we are based on poky, just adding a layer for some custom stuff Jan 10 16:56:17 (preferrably in your distro configuration file in your own layer) Jan 10 16:56:32 when you start adding overrides, you now have a custom distro.. Jan 10 16:56:39 true Jan 10 16:56:40 you can inherit the poky distro from your own distro Jan 10 16:56:59 yourlayer/conf/distro/yourdistro.conf: Jan 10 16:57:04 include conf/distro/poky.conf Jan 10 16:57:16 (veirfy that everything is the way you want with bitbake -e) Jan 10 16:57:33 so DISTRO = "poky" alone won't do it anymore? Jan 10 16:57:50 you would change DISTRO = "poky" to DISTRO = "yourdistro" Jan 10 16:58:22 whats the benefit of doing it via DISTROOVERRIDES vs normal OVERRIDES? Jan 10 16:58:26 (you can call yourdistro 'anything' you want.. Jan 10 16:58:48 where would you add to the normal overrides? really the only places are local.conf, distro.conf or machine.conf files Jan 10 16:59:00 (you can do it in other places, but it's really not a good idea) Jan 10 16:59:02 site.conf Jan 10 16:59:13 which is where we dump all our central layer configuration stuff Jan 10 16:59:16 site.conf is equivalent to local.conf Jan 10 16:59:21 i.e. layer/conf/site.conf Jan 10 16:59:46 you want any overrides you add prior to the forcevariable though... that really does need to be the last one Jan 10 16:59:51 well yes, but local conf is per machine, site.conf for everyone using the layer.. but it wokred for us Jan 10 17:00:24 OVERRIDES_append = ":${FEED}" seemed to do the trick? Jan 10 17:00:25 site.conf is loaded (roughly) equivalent to local.conf -- the idea is to centralize changes to local.conf Jan 10 17:00:44 that will add the feed after forcevariable -- it SHOULD work, but it's not really a good idea.. you want forcevariable as the last item Jan 10 17:01:26 if you don't have it last, it prevents anyone from debugging or otherwise working on the system from doing a final override.. they'd be forced to define your feed.. (which might be fine, but it wouldn't be int he community docs and best behavior tricks) Jan 10 17:01:44 interestingly enough its not last right now, libc-glibc comes after it Jan 10 17:02:03 libc overrides should be prior to forcevariable Jan 10 17:02:20 OVERRIDES="linux-gnueabi:arm:build-linux:pn-libdsvdc:armv7a:imx:dss20:poky:class-target:forcevariable:libc-glibc" is how it looks right now Jan 10 17:02:22 without my changes Jan 10 17:02:40 what is the raw overrides line BEFORE it's evaluated/ Jan 10 17:02:48 (will be in a comment above that line in the -e output) Jan 10 17:03:28 /poky/meta/conf/distro/include/tclibc-glibc.inc adds the ${LIBCOVERRIDE} Jan 10 17:03:42 so poky does that Jan 10 17:04:20 that looks like a bug to me.. typically LIBC overrides is the item immediately before forcevariable Jan 10 17:04:27 * fray checks his current system Jan 10 17:04:34 its poky 2.5.1 btw Jan 10 17:06:32 but I could just use _prepend, no? that'd put it first so way before forcevariable Jan 10 17:06:32 ya, current system is: Jan 10 17:06:33 # "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${MACHINEOVERRIDES}:${DISTR Jan 10 17:06:33 OOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:forcevariable" Jan 10 17:06:42 so that could very well be a bug in 2.5.1 Jan 10 17:06:50 current is..? you re on 2.6 or master? Jan 10 17:07:00 that was master Jan 10 17:07:11 we did not come to updating to 2.6 yet Jan 10 17:07:15 but we plan to do it Jan 10 17:07:18 looking in 2.6 now Jan 10 17:08:17 2.6: # "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${MACHINEOVERRIDES}:${DISTR Jan 10 17:08:17 OOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:forcevariable" Jan 10 17:08:25 so thats fine there too Jan 10 17:08:33 looking in 2.4 Jan 10 17:08:38 (I don't have 2.5) Jan 10 17:08:41 :) Jan 10 17:09:52 # "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINE Jan 10 17:09:52 OVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable${LIBCOVERRIDE}" Jan 10 17:10:55 ya.. it wasn't 'right' in 2.4 either Jan 10 17:11:11 checking 2.2 Jan 10 17:11:50 and my 2.2 install doesn't work.. whee Jan 10 17:11:55 :) Jan 10 17:12:20 ok.. fixed.. Jan 10 17:12:48 so, I kind of missed the answer now, what again was the benefit of going via distro overrides instead of just using a custom variable that is internal to the custom layer? Jan 10 17:12:54 Hmm.. maybe it's still unhappy.. Jan 10 17:13:17 what you are doing is defining a customized distribution.. so using the DISTROVERRIDES is really the right place to do this.. Jan 10 17:13:44 Unless you can guarantee that this 'FEED' change doesn't change anything 'distribution' wise.. (which would include configuration, patches, etc) Jan 10 17:13:46 so its less technical but more in terms of correctness? just trying to understand Jan 10 17:13:59 ya.. 2.2 overrides is the same.. Jan 10 17:14:07 maybe it was a long standing bug that was fixed in 2.6? Jan 10 17:14:14 yes Jan 10 17:14:31 'correctness' vs 'it works anyway' Jan 10 17:14:45 I should probably pull in that fix from 2.6 then Jan 10 17:14:53 as I've told people, bitbake/OE give you all of the rope you need to hang yourself... it's up to you to not Jan 10 17:15:07 hehe :) Jan 10 17:15:08 it's only a bug if you rely on that specific behavior.. Jan 10 17:15:18 the libc-glibc override is rarely used.. so likely not a problem.. Jan 10 17:15:24 but forcevariable was meant to be last Jan 10 17:15:29 (highest precedence) Jan 10 17:15:30 I do not think we use it in our layer Jan 10 17:15:37 probably not.. most won't Jan 10 17:15:46 btw would _append_feed_machine work? like, double selector? Jan 10 17:15:48 it's only useful for recipes that have patch or config differences between glibc and musl Jan 10 17:16:04 yes.. it evaluates them in order.. Jan 10 17:16:12 so _append_feed_machine would eval machine first, then feed.. Jan 10 17:16:17 so if machine is not set, then feed is ignored Jan 10 17:16:31 (not set, I mean doesn't match the current machine override) Jan 10 17:16:31 oh so actually append_machine_feed would be the correct order Jan 10 17:16:40 that would match feed, then machine Jan 10 17:16:41 first check feed, then machine Jan 10 17:16:44 yeah Jan 10 17:16:58 but basically I see that this mechanism is exactlyl what I need to implement the requirement Jan 10 17:17:11 the order really matters only if you have a lot of overrides as it can save a very small amount of time in evaluation Jan 10 17:20:02 ah Jan 10 17:20:47 thanks a lot for the explanations! I was especially missing the point with adding ${VAR} to OVERRIDES as I could not figure out how to actually trigger the override to be used, but its clear now Jan 11 00:00:25 khem: did musl and arm64 ever work well: struct prctl_mm_map --> https://pastebin.com/z7HNMedg Jan 11 00:01:51 of course maybe it's just strace, let me try another package. Jan 11 00:19:12 top builds fine. I'll continue on this later Jan 11 00:20:42 psutils that is. Jan 11 00:33:38 * armpit has tried musl arm64.. not pushed it hard thou **** ENDING LOGGING AT Fri Jan 11 02:59:57 2019