**** BEGIN LOGGING AT Fri Apr 03 02:59:56 2020 Apr 03 04:39:55 im getting the below build error with openssl (jethro) Apr 03 04:39:56 | sha256-x86_64.s: Assembler messages: Apr 03 04:40:29 jethro_ide/sources/poky/meta/recipes-connectivity/openssl/openssl_1.0.2h.bb, do_compile) failed with exit code '1 Apr 03 04:52:24 whats the Assembler Message ? Apr 03 05:44:20 sha256-x86_64.s: Assembler messages: Apr 03 05:44:20 `-' Apr 03 09:34:22 hi just added two layers to conf and running bitbake-layers show-layers i get ERROR meta-development is not compatible with core layer witch only supports these series: layer is compatible with zeus warrior. I have not included meta-development in my conf/bblayer ? This has not been a problem before? Apr 03 09:35:45 spiel: that doesn't sound right. Apr 03 09:36:32 The whole error message: ERROR: Layer meta-development is not compatible with the core layer which only supports these series: dunfell (layer is compatible with zeus warrior) Apr 03 09:37:38 spiel: and you claim (e.g. have at least triple-checked) that your build/conf/bblayers.conf does *NOT* refer to that meta-development layer? Apr 03 09:37:44 hmm. It seems to be the layer I have made myself Apr 03 09:38:24 I will tripple check. Give me two sec Apr 03 10:09:06 LetoThe2nd: Sorry, you were right, there was something wrong with my layer.conf in my new layer. Apr 03 10:09:13 :) Apr 03 10:55:10 getting the below build error while compiling openssl (jethro). Apr 03 10:55:13 | sha256-x86_64.s: Assembler messages: Apr 03 10:55:13 expression `-' Apr 03 10:56:10 chola79: since when, and on which host distribution? Apr 03 10:58:15 (and leaving aside the fact that jethro is basically out of support since more than 3 years) Apr 03 10:58:17 i am building on RHEL server 7.6 Apr 03 10:58:24 i am able to build the sumo version Apr 03 10:58:32 but not the Jethro Apr 03 10:59:37 chola79: if i had to guess then, try on a distro that is from the jethro era. Apr 03 11:04:47 ok, i tried it on Ubuntu 16.04, it works! Apr 03 11:06:04 see, there is a reason we call it "End Of Life" :) Apr 03 11:36:54 :) Apr 03 11:37:03 thanks Apr 03 11:44:36 New news from stackoverflow: Building GO application fails with error subpackage missing Apr 03 11:55:27 Hi, I need to overwrite the DEFAULTTUNE. I did this in my conf/local.conf but as this should rather be build host specific configurations I reckon that there is a better place to do that. Where would that be? I was thinking maybe to have a `conf/machine/myownmachine.inc` configuration by I seem to fail to `require` the confugration from another Apr 03 11:55:27 layer to overwrite the DEFAULTTUNE there. Am I somewhere on the right track here? Apr 03 11:57:22 feel free to drop comments here https://stackoverflow.com/questions/61011386/override-version-of-a-sub-dependency-causes-c-extension-compilation-failure Apr 03 11:57:24 :) Apr 03 12:04:24 emrius: DEFAULTTUNE is an absolute classic to go into your MACHINE configuration file Apr 03 12:05:40 LetoThe2nd Thanks! thank I will dig deeper there Apr 03 12:07:11 But wait. That means to overwrite the machine configuration of the BSP provider? Assuming that their configuration is wrong? Apr 03 12:09:25 emrius: create an own mymachine, include their machine and just overwrite below the inclusion. Apr 03 12:09:50 LetoThe2nd Ok. Will do! Apr 03 12:14:43 New news from stackoverflow: override `DEFAULTTUNE`. Best (correct) practice Apr 03 12:16:24 heureka! working. I did something wrong on including the original bsp machine configuration before.... Apr 03 13:21:39 LetoThe2nd: ever do a live coding on developing kernel modules using the sdk? Apr 03 13:27:11 anyone around with an arch system that hits the seccomp issue with a few minutes to test a patch? Apr 03 13:27:34 JPEW: I'm leaning towards my patch fwiw Apr 03 13:28:16 RP: neutering seccomp? disappointed i didn't think of that at the time. Apr 03 13:28:33 rburton: yes, me too. http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=08e56b4dbfea703a979c26998fe3ca607c560731 Apr 03 13:28:57 why does the comment says renameat2 Apr 03 13:29:29 rburton: heh, copy and paste error. I can delete the 'else too Apr 03 13:29:49 was about to say the else is beyond pointless :) Apr 03 13:33:30 stupid question: does this mean yocto might get selinux support ? Apr 03 13:33:38 rburton: Better: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=d675ff53d3ccbc6bd7db5f067d331bf3f94de5cd Apr 03 13:33:54 kroon: no Apr 03 13:34:00 kroon: http://layers.openembedded.org/layerindex/branch/master/layer/meta-selinux/ Apr 03 13:34:25 kroon: I think there are layers doing that Apr 03 13:34:45 RP, Crofton|road, aha Apr 03 13:40:09 RP, hmm I think you meant "incompatible" in the commit message ? Apr 03 13:41:08 kroon: indeed, fixed Apr 03 13:48:58 RP: Do we know why SOURCE_DATE_EPOCH is whitelisted? Apr 03 13:50:19 JPEW: U-Boot, and I think other things too, use that for consistent build time for reproducible binaries Apr 03 13:50:38 JPEW: yes, you'd get different values at parse time verses run time Apr 03 13:50:46 I'm pretty sure others too and we didn't invent the name, vagrantc told us to use it Apr 03 13:51:21 Tartarus: its indeed a standard and we use it in our code for the same reason Apr 03 13:57:03 RP: Ah, right. You're patch seems fine... I suppose any variable that relies on external state like that would *have* to be whitelisted for the same reason Apr 03 13:58:23 JPEW: yes, that is my thinking Apr 03 13:58:48 JPEW: we do already exclude these values, this just changes the timing of it in the code and avoids some execution Apr 03 14:45:13 New news from stackoverflow: override `DEFAULTTUNE` and other machine configuration parameters Apr 03 15:03:19 I have a problem with a kernel package name change not being propagated to the packagegroup-machine-base Depends: field (bumped kernel from 5.3.8 to 5.3.18, and packagegroup-machine-base with its "Depends: kernel-image-5.3.8-yocto-standard" for some reason does not get rebuilt, which naturally fails at image creation time Apr 03 15:06:25 Accurding to bitbake -e, we should have RDEPENDS_packagegroup-machine-base=" kernel-image", how does this replaced by a full version ? Apr 03 15:21:30 yann: Have you checked the dependency graph for your image (via `bitbake -g `) ? Make sure packagegroup-machine-base and the kernel recipe are there, if not you may have a dependency issue Apr 03 15:23:10 I mean the recipe that provides packagegroup-machine-base which is packagegroup-base Apr 03 15:27:26 I had that last point already :) Apr 03 15:45:23 New news from stackoverflow: Building GO application fails with error subpackage missing [closed] Apr 03 15:47:27 paulbarker: I see no dep from packagegroup-base to anything kernel Apr 03 15:48:24 how is it this "kernel-image" string got "expanded" to "kernel-image-5.3.8-yocto-standard" to start with ? (note: that's still sumo here) Apr 03 15:52:18 the kernel.bbclass does it. see: d.setVar('PKG_%s-image-%s' % (kname,typelower), '%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) Apr 03 15:55:51 yann, zeddii: I think the issue is that lack of dependency, if the dep was there the expanded string will be updated Apr 03 15:56:08 Check your kernel recipe and any appends Apr 03 15:57:06 yah, that line is just the package part, what it provides to match a versioned dependency. Apr 03 16:06:07 oh, so that's expanded in do_packagedata ? Apr 03 16:08:13 but what's the point in doing expansion before building the package, in fact ? wouldn't opkg be able to match "kernel-image" to the package providing it ? Apr 03 16:31:58 Hey, I'm running qemu and it get's stuck with a message "A start job is running for /dev/mmcblk0p4". AFAIK the partition mmcblk0p4 is due to be mounted but the device is missing. Is this thought reasonable? How can I define the devices for qemu? basically prividing what usually would be defined in /etc/fstab? Apr 03 17:40:17 hello, I have a simple, maybe dumb, question about yocto. What is the situation that I must consider myself obliged to create my own layer in yocto project ? Apr 03 17:40:56 what is the big use of creating an own layer and instead of editing what you want from local.conf file Apr 03 17:41:17 presumably your layer is vesion controlled. Apr 03 17:41:22 version controlled. Apr 03 17:41:33 and not transient like local.conf Apr 03 17:41:41 but if you are ok with transient, then local.conf is fine. Apr 03 17:42:44 zeddii sorry but what do you mean with " version controlled " ? Apr 03 17:43:11 meaning, if you are working on a layer, I hope you have it in git. Apr 03 17:43:50 if you are just creating layers and leaving them lying around that's ok too, but obviously you aren't tracking changes in that workflow, etc. Apr 03 17:46:40 I am not making too big changes , I just add some packages , libraries , features , to my generated image, or sometimes modify package version .. Apr 03 17:46:52 does this need to create my own layer ? Apr 03 17:47:06 freeuser: A layer lets you structure things and split things up so you've not gone a huge messy local.conf Apr 03 17:47:30 Making a layer is easy Apr 03 17:50:04 paulbarker can you give me please an example that make me think of creating a layer ? Apr 03 17:50:32 freeuser: An example of how to create a layer? or an example of why you'd want to create one? Apr 03 17:50:53 why I would want to create a layer Apr 03 17:51:35 To structure and version control the modifications you need to make, or if you need to add new recipes (can't do that from local.conf) Apr 03 17:53:24 paulbarker humm I see .. Apr 03 18:10:08 <[Sno]> RP: is initscripts / init-system-helpers now fine enough for testing? Apr 03 18:21:23 Hi all Apr 03 18:22:37 <[Sno]> otavio: will do some LSDK-20.04 later - but u-bot-qoriq don't build Apr 03 18:23:42 I am trying to set up Yocto to build for a STM32 DK2 Discovery Board but am having some difficulty as there does not appear to be any step by step instructions for this board anyware ? Apr 03 18:25:49 Saur: we need a small patch. https://github.com/u-boot/u-boot/commit/bdaa73a5b392.patch also does the trick Apr 03 18:26:33 [Sno]: we need a small patch. https://github.com/u-boot/u-boot/commit/bdaa73a5b392.patch also does the trick Apr 03 18:26:43 <[Sno]> :) Apr 03 18:26:55 [Sno]: but merged new u-boot too Apr 03 18:27:01 otavio: And here I thought I was needed... ;) Apr 03 18:27:06 <[Sno]> You have a PR in github - that's oky, isn't it? Apr 03 18:27:21 [Sno]: merged Apr 03 18:27:26 <[Sno]> excellent Apr 03 18:28:10 <[Sno]> I see that I do qoriq tests with the newly ordered honeycomb lx2160 Apr 03 18:38:16 :-) Apr 03 18:42:38 <[Sno]> otavio: my co-developer at libstatgrab (https://github.com/libstatgrab/) created some CI tests on Gitlab for libstatgrab (https://github.com/libstatgrab/libstatgrab -> https://gitlab.com/libstatgrab/libstatgrab) - better than Github allowes - can you imagine something similar for meta-freescale? Apr 03 18:49:08 Why better to use this than GitHub actions? Apr 03 18:51:13 because it was there first Apr 03 18:51:26 errr, ignore me, wrong channel. Apr 03 18:52:09 [Sno]: Apr 03 18:52:35 <[Sno]> otavio: I'm not very familiar with Github actions and don't know the limitations Apr 03 18:57:48 [Sno]: but we have CI inside O.S. Systems. I'd love to move it to GitHub for sure. Apr 03 19:19:47 <[Sno]> otavio: I just see that QorIQ isn't covered in that CI Apr 03 19:20:19 <[Sno]> otavio: that's why an open one would help getting patches to extend coverage Apr 03 19:24:45 [Sno]: if you are willing to help to set it up, I am more than happy to help Apr 03 19:32:33 So i am trying to bitbake but am getting the following error: "No recipes available for: Apr 03 19:32:33 /home/mfny/Yocto/DK2/layers/meta-st-stm32mp/recipes-kernel/linux-firmware/linux-firmware_git.bbappend" and the file referenced has the following contents: https://pastebin.com/CrgpkXpC Apr 03 19:32:50 anyone know what is going on ? Apr 03 19:33:38 mfny: It means there is no linux-firmware_git.bb in any of the layers you have included in "bblayers.conf". Apr 03 19:34:15 Saur: I am using the BSP layer from here https://github.com/STMicroelectronics/meta-st-stm32mp so I did not write any of this .. Apr 03 19:34:30 <[Sno]> otavio: I will take a look what I can do Apr 03 19:34:37 mfny: so contact them and report it there Apr 03 19:34:41 <[Sno]> would of course easier to jump in :D Apr 03 19:34:50 [Sno]: :-) Apr 03 19:35:27 Saur: that file does exist in the directory it is being looked for though Apr 03 19:35:52 [Sno]: https://code.ossystems.com.br/gitweb?p=osyis.git;a=summary is what we use to make it easier to automate a build Apr 03 19:36:17 <[Sno]> otavio: for the very first shot, I set up some CI in Safran Data Systems - and after that I go forward Apr 03 19:39:38 <[Sno]> otavio: bookmarking that to come back on that later (~June or later) Apr 03 19:40:36 mfny: My guess is that you are using the latest version of meta-st-stm32mp with and older version of OE-Core than Zeus. The linux-firmware recipe used to have a date in the name as version, but since Zeus the version is "git". Apr 03 19:41:16 mfny: You must use a version of meta-st-stm32mp that mateches the version of OE-Core that you use. Apr 03 19:41:38 Saur: This is what I have in my bblayers.conf https://pastebin.com/RYcrgdxM pretty much default apart from the last 3 lines Apr 03 19:42:45 mfny: That tells nothing about what versions of the layers that you are mixing. Apr 03 19:44:18 Saur: it is the other way around. Now it has a date on linux-firmware recipe Apr 03 19:45:51 otavio: Right, correct you are. Which means that the version of meta-st-stm32mp being used is aimed for an older version of OE-Core. Apr 03 19:48:49 Saur: it is unclear what branch meta-st-stm32mp is expecting, the readme for the package does not explicitly say Apr 03 19:49:10 [Sno]: Its going to break as there is no maintainers entry for the new recipe Apr 03 19:49:38 mfny: It is expecting thud (see LAYERSERIES_COMPAT_stm-st-stm32mp in conf/layer.conf). Apr 03 19:49:44 <[Sno]> RP: add me and mail me if something breaks Apr 03 19:50:37 [Sno]: It will break. No question. Apr 03 19:50:41 <[Sno]> RP: but that's weird - initscripts is broken and new recipe to fix that requires new maintainer o.O Apr 03 19:51:02 <[Sno]> RP: what shall I do to fix that? Apr 03 19:51:07 [Sno]: Every recipe in oe-core has to have a maintainer entry Apr 03 19:51:16 Its enforced by the CI Apr 03 19:51:23 <[Sno]> okay ... Apr 03 19:51:47 [Sno]: Its really late in the release cycle to be going through this kind of fixing of a totally new recipe :( Apr 03 19:52:20 <[Sno]> RP: that's fine - adding it after release is cool Apr 03 19:52:34 [Sno]: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=e7729877399c18b1d73d224e611cc258832902ec gives a hint on what you need to add Apr 03 19:52:39 <[Sno]> it's just a question whether I can do something now Apr 03 19:52:43 (which file anyway) Apr 03 19:54:07 <[Sno]> RP: so the patch would require touching meta/conf/distro/include/maintainers.inc ? Apr 03 19:54:22 <[Sno]> regardless whether now or after release Apr 03 19:54:23 [Sno]: "oe-selftest -r distrodata.Distrodata.test_maintainers" is the test which will fail Apr 03 19:54:29 [Sno]: correct Apr 03 19:55:06 Saur: so doing "git clone -b thud git://git.yoctoproject.org/poky.git" and "git clone -b thud git://git.openembedded.org/meta-openembedded" should make it happy with the versions then ? Apr 03 19:55:31 mfny: Probably Apr 03 19:56:36 <[Sno]> RP: I wondered that's even not in master-next - I told last week, that it's broken since long time and backporting fix after release or have it for 3.2 is better than keep it broken :D Apr 03 19:59:00 also since there seems to be no dedicated image for this BSP i use something like core-image-base for bitbake right ? Apr 03 19:59:26 [Sno]: We've just got our hands full of issues and with that patch it clearly needed more work Apr 03 20:01:21 <[Sno]> RP: when I know what kind of work is needed, I'm already on it and can do something Apr 03 20:07:23 mfny: You have three images in recipes-st/images. But I have no idea what any of them do. Apr 03 20:42:14 RP: What is the project policy on fixing broken patches? Is it okay to provide change to the patch or should it be regenerated? A new supplemental patch? Apr 03 20:43:09 The change in question: https://pastebin.com/ntNQ6ugz Apr 03 20:44:28 For further context: http://bugzilla.yoctoproject.org/show_bug.cgi?id=13853 Apr 03 20:44:30 Bug 13853: normal, Undecided, ---, jpuhlman, NEW , buildtools-extended-tarball: link search for librt not relocated Apr 03 20:46:26 New news from stackoverflow: Override compatibility of recipe Apr 03 20:59:23 hello world! Apr 03 21:01:46 could anyone point out me in a direction to figure out how to change yoctos default image lang to utf-8? Apr 03 21:04:01 jpuhlman: its fine to patch the patch Apr 03 21:13:18 RP: Thanks. Apr 03 22:16:35 Saur: those 3 images seem to be seprate parts of the overall image, and i have no idea how to build them all at the same time ? Apr 03 22:17:15 atm i am just building core-image-minimal, to make sure the very basics work Apr 03 22:17:41 will work out the rest later ? this seem sane ? Apr 03 22:18:23 mfny: Sorry, I have no experience with that layer so I do not know anything about how it is supposed to be used. You will have to read its documentation or contact its maintainer if you need more information on how it is supposed to be used. Apr 03 22:32:46 any advise setting the locales for the images produced? Apr 03 22:35:45 Saur: it seems i may be making this more difficult then it needs to be, there is an official distro build package from stmicro based on yocto but i could not quite figure out how it worked but ive just looked again and yeah .. Apr 04 01:52:04 RP: sadly the v2 of icu patch failed for me with build from scratch where it use cross AR and RANLIB, so I sent a v3, problem is that I dont have enough compute to detect all these cases took some time, but v3 should be good Apr 04 02:15:43 please drop v2 and take v3 at earliest **** ENDING LOGGING AT Sat Apr 04 03:00:20 2020