Thursday, 2022-05-05

*** nemik <nemik!> has quit IRC (Ping timeout: 276 seconds)00:04
*** nemik <nemik!~nemik@> has joined #yocto00:04
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)00:12
*** Wouter0100 <Wouter0100!> has joined #yocto00:13
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has quit IRC (Ping timeout: 240 seconds)00:29
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has joined #yocto00:33
*** dreese <dreese!> has quit IRC (Remote host closed the connection)00:43
*** dreese <dreese!> has joined #yocto00:43
*** dreese <dreese!> has quit IRC (Remote host closed the connection)00:44
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)01:01
*** dreese <dreese!> has joined #yocto01:05
*** dreese <dreese!> has quit IRC (Remote host closed the connection)01:17
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 248 seconds)01:28
*** nemik <nemik!> has joined #yocto01:28
*** dreese <dreese!> has joined #yocto01:32
*** rber|res <rber|res!~rber|> has joined #yocto01:32
*** nemik <nemik!> has quit IRC (Ping timeout: 246 seconds)01:34
*** RobertBerger <RobertBerger!~rber|> has quit IRC (Ping timeout: 246 seconds)01:34
*** nemik <nemik!~nemik@> has joined #yocto01:34
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)01:34
*** starblue <starblue!> has quit IRC (Ping timeout: 260 seconds)01:37
*** starblue <starblue!> has joined #yocto01:38
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 246 seconds)01:39
*** nemik <nemik!> has joined #yocto01:39
*** nemik <nemik!> has quit IRC (Ping timeout: 260 seconds)01:44
*** nemik <nemik!~nemik@> has joined #yocto01:44
*** camus <camus!~Instantbi@2409:8a1e:9112:6900:50de:4772:36f2:d662> has joined #yocto01:58
*** sakoman <sakoman!> has joined #yocto02:29
*** kroon <kroon!> has joined #yocto02:34
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 260 seconds)03:14
*** nemik <nemik!> has joined #yocto03:14
*** nemik <nemik!> has quit IRC (Ping timeout: 256 seconds)03:19
*** nemik <nemik!~nemik@> has joined #yocto03:19
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto03:55
*** TundraMan <TundraMan!> has joined #yocto04:02
*** marka <marka!> has quit IRC (Ping timeout: 250 seconds)04:02
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:34
*** tlwoerner <tlwoerner!> has quit IRC (Remote host closed the connection)04:55
*** tlwoerner <tlwoerner!> has joined #yocto04:55
*** davidinux <davidinux!> has quit IRC (Ping timeout: 260 seconds)05:00
*** davidinux <davidinux!~davidinux@> has joined #yocto05:00
moto-timokanavin: so much ♥️ thank you for the patch bomb05:08
moto-timoZero time to look05:08
*** thomas_ <thomas_!> has joined #yocto05:10
*** mihai <mihai!~mihai@user/mihai> has joined #yocto06:10
*** ThomasRoos <ThomasRoos!> has joined #yocto06:17
*** rob_w <rob_w!> has joined #yocto06:18
*** mckoan|away is now known as mckoan06:20
mckoangood morning06:20
thomas_good morning06:28
*** tlwoerner <tlwoerner!> has quit IRC (Remote host closed the connection)06:28
*** tlwoerner <tlwoerner!> has joined #yocto06:29
RPrburton: reproducible failed with the new sstate/hashequiv versioning06:37
*** Wouter0100 <Wouter0100!> has quit IRC (Remote host closed the connection)06:47
*** Wouter0100 <Wouter0100!> has joined #yocto06:47
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 276 seconds)06:49
*** nemik <nemik!> has joined #yocto06:49
*** ThomasRoos <ThomasRoos!> has quit IRC (Ping timeout: 252 seconds)06:50
*** nemik <nemik!> has quit IRC (Ping timeout: 256 seconds)06:54
*** nemik <nemik!~nemik@> has joined #yocto06:54
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 260 seconds)06:56
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:c8d1:3df4:ffd5:5d99> has quit IRC (Quit: vladest)06:56
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:f94b:c9ed:2b00:b562> has joined #yocto06:57
*** davidinux <davidinux!~davidinux@> has joined #yocto06:57
*** michalkotyla <michalkotyla!> has quit IRC (Quit: michalkotyla)06:59
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:f94b:c9ed:2b00:b562> has quit IRC (Remote host closed the connection)07:00
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:c3db:5341:4df1:8ad2> has joined #yocto07:00
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:c3db:5341:4df1:8ad2> has quit IRC (Remote host closed the connection)07:03
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:b43d:613b:a6e0:1a49> has joined #yocto07:03
*** michalkotyla <michalkotyla!> has joined #yocto07:05
*** kranzo <kranzo!> has joined #yocto07:08
*** florian_kc <florian_kc!> has joined #yocto07:08
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto07:08
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 250 seconds)07:17
*** olani <olani!~olani@> has joined #yocto07:18
*** dev1990 <dev1990!> has joined #yocto07:24
thomas_Whats the difference between += and _append? Why should _append be used in local.conf instead of += ?07:25
LetoThe2ndthomas_: rather :append by the way, there was a syntax change about a year ago.07:26
thomas_LetoThe2nd, yes, I've read about it in the mega manual. But why :append over += ?07:26
LetoThe2ndthomas_: += can be handy at times, but its more blunt because it also adds a space automatically. but both should do their respective duties. oh, and IIRC you can't use overrides on +=, but on :append07:27
thomas_Okay, I'm just wondering. I've got some Seminar Handout from Avnet in my hands, and they said rather use append than += in local.conf. But not the reason behind it :)07:29
LetoThe2ndthomas_: there might be deeper reasons too, but on the top level, :append is just way more flexible.07:30
thomas_got it. thanks07:30
*** sashko <sashko!> has joined #yocto07:34
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 260 seconds)07:39
*** nemik <nemik!> has joined #yocto07:39
*** florian <florian!> has joined #yocto07:40
*** nemik <nemik!> has quit IRC (Ping timeout: 260 seconds)07:43
*** nemik <nemik!~nemik@> has joined #yocto07:44
LetoThe2ndthomas_: and the updated version at the upcoming summit, so... go register! :-)
qschulzthomas_: if you have a variable in a recipe with ?=, using += in local.conf will override the variable with the content of the += instead oaf adding it07:46
qschulzusing :append allows to add the content of the += to the one in ?=07:46
qschulzadd the conte of the :append*07:47
thomas_ahhhhhh, yes that makes sense qschulz :) thanks07:47
LetoThe2ndagain what learned!07:48
qschulzthomas_: also, strive to have as little as possible in local.conf07:48
LetoThe2ndi will forget and relearn the next time qschulz talks about it, but hey, makes me feel good today.07:48
thomas_Its on slide 14 LetoThe2nd07:49
LetoThe2ndyeah, keep local.conf as KISS as possible.07:49
*** ThomasRoos <ThomasRoos!> has joined #yocto07:50
*** tnovotny <tnovotny!> has joined #yocto07:52
thomas_How does the Hands on lab work on tuesday? Do I need to prepare a local yocto instance beforehand?07:57
thomas_I've never heard about digital ocean07:58
qschulzthomas_: IIRC there will be cloud instances you'll have ssh access to07:58
thomas_Ah okay. I'll ask my boss if he give me the time to attend :)07:58
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 260 seconds)07:59
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer)07:59
*** davidinux <davidinux!~davidinux@> has joined #yocto08:00
*** eggman <eggman!eggman@libera/staff/eggman> has quit IRC (Quit: brb)08:02
*** eggman <eggman!eggman@libera/staff/eggman> has joined #yocto08:03
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)08:06
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto08:09
kanavinmoto-timo, cheers. I think this brings oe-core entirely up to date (as of May 1st), save for some updates on hold for known issues.08:10
*** Guest49 <Guest49!~Guest49@> has joined #yocto08:10
kanavine.g. setuptools :D08:10
Guest49Hi! "...using the old override syntax. Please convert this layer/metadata before ....newer bitbake".      Is there a web page or something explaining how to convert?08:12
Guest49ah cool. Thank you08:15
*** goliath <goliath!~goliath@user/goliath> has joined #yocto08:20
*** ptsneves <ptsneves!~ptsneves@2a00:f41:7046:92e2:5896:fa88:e59a:cd37> has joined #yocto08:38
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 248 seconds)08:39
*** nemik <nemik!> has joined #yocto08:39
*** nemik <nemik!> has quit IRC (Ping timeout: 248 seconds)08:44
*** nemik <nemik!~nemik@> has joined #yocto08:44
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 248 seconds)08:48
*** nemik <nemik!> has joined #yocto08:49
thomas_Whats the difference between IMAGE_FEATURES and EXTRA_IMAGE_FEATURES?  basically the same keywords are listed for both?08:52
*** nemik <nemik!> has quit IRC (Ping timeout: 276 seconds)08:54
*** nemik <nemik!~nemik@> has joined #yocto08:54
ptsnevesdoes anybody have an idea why oe_runmake-task-compile() {} does not override for the kernel compile/08:55
T_UNIX[m]ptsneves:  have you had a look at the environment (`bitbake -e some-recipe`)?08:59
qschulzptsneves: I've never seen oe_runmake-task-compile before.. what are you trying to achieve?09:00
T_UNIX[m]<thomas_> "Whats the difference between..." <- > Although the functions for both variables are nearly equivalent, best practices dictate using `IMAGE_FEATURES` from within a recipe and using `EXTRA_IMAGE_FEATURES` from within your `local.conf` file, which is found in the Build Directory.09:00
ptsnevesi looked directly at the run.do_compile and it is not there. The task is also not triggered.09:00
ptsnevesI am trying to manually log the output of make so as to create a bbwarn if a magic string comes up.09:02
ptsnevesoe_runmake-task-kernel-compile() {09:02
ptsneves  bbwarn "Capturing do compile"09:02
ptsneves  oe_runmake_call "$@" | tee log || die "oe_runmake failed"09:02
ptsneves  grep -qi GENSEED log && bbwarn "Generated a new seed"09:02
ptsnevessomething along the way09:02
*** florian_kc <florian_kc!> has joined #yocto09:02
T_UNIX[m]could anybody tell me how I can have a look at a recipe's environment (`-e`) within the context of some image (especially a certain set of `IMAGE_FEATURES`)?09:03
qschulzT_UNIX[m]: cannot, recipes are sandboxed09:03
qschulzyou can check what's the value of a variable in a recipe, but you cannot check the value of a variable in another recipe09:04
*** Tyaku <Tyaku!> has joined #yocto09:04
T_UNIX[m]It appears that a recipe is not rebuild, even if I change its `PACKAGECONFIG` depending on its `IMAGE_FEATURES`.09:04
qschulzT_UNIX[m]: where do you set IMAGE_FEATURES?09:05
thomas_Thanks T_UNIX[m]09:05
kroonI wasn't aware that you can use overrides based on task. Where is that set ? And how do I then dump the environment for a specific recipe task ?09:05
qschulzkroon: you can but usually it's VAR:task-compile09:06
qschulzptsneves: so I think it should just be oe_runmake:task-compile instead?09:06
ptsneveskroon you can. It is an obscure feature, that i needed to research as i did not remember exactly the syntax. The docs are sparse
ptsneveswill try09:06
qschulzptsneves: you're looking at docs that's at least 5 years old at this point09:07
qschulzalso, use _ instead of : if you're on a release older than dunfell09:08
ptsnevesseems my bookmark is out date. I am on dunfell09:08
qschulzif you are on dunfell or later, make sure to use the latest version of the release, and you'll have support for both _ and : override syntax09:08
ptsnevesi did not know that the : syntax was backported to the dunfell brnach09:08
qschulzptsneves: dunfell is a special case, we have docs both in the old website and in the newer one09:08
qschulzthe docs for dunfell on the old website stops at 3.1.4 (included)09:09
qschulzthere are patches being worked on to display a banner on the old website09:09
ptsnevesthe new docs look great. Would it be too much effort and put the release name (dunfell) in the version combo box?09:09
TyakuHi, Is there a way to debug "*** buffer overflow detected ***" on a release software built by bitbake recipe ? (for example to get the stack trace ?)09:09
ptsnevesTyaku yes. Generate the debug symbols, get the rootfs and follow this guide i did
qschulzptsneves: I think that's doable, I've a patch somewhere for that but was waiting to fix a bigger change to send it09:12
ptsnevesqschulz the oe_runmake:do_compile does not work either. It seems that for functions the override does not work09:12
qschulzptsneves: I never suggested that09:14
ptsnevesoops..did you mean oe_runmake:task-comple() {}?09:15
Tyakuptsneves: When you speak about debug symbols, Do you speak about the CFLAG -g ? Because when I read the run.do_compile of my recipe, I see something like this: export CFLAGS=" -O2 -pipe -g ......09:16
qschulzptsneves: yup09:16
qschulzand if that does not work, then oe_runmake_task-compile09:17
qschulzptsneves: also, make sure you're actually overriding the correct task, because the kernel recipes usually have a few intermediate tasks before compile09:17
ptsnevestried both and nope. The task is do_compile so i am pretty sure of that(?)09:18
ptsnevesi will just override for the whole recipe and be done with it :(09:18
qschulzptsneves: not entirely sure that overrides are supported for shell functions which aren't tasks09:19
ptsnevesyeah probably the case.09:19
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)09:20
ptsnevesI think there is a workaround by treading the shell function as a variable, meaning not using the () but direct = assignment, but it is besides my current goal09:20
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto09:21
ykronsHi all09:27
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)09:28
*** Guest49 <Guest49!~Guest49@> has quit IRC (Quit: Client closed)09:29
ykronsI'm facing an issue to update a patch for a newer kernel. I think I have successfully used devshell and quilt in the past for that (on a zeus or maybe older version) and today with a dunfell kernel, it seems something has changed and quilt can't find patches. Is quilt still used or replaced ?09:30
qschulzykrons: devtool should have everything you need to create patches and add them to the original recipe, so maybe try that09:31
qschulzbut AFAIK, no, quilt is still used by default for patching09:31
ptsnevesykrons as qschulz says. It is much more work to do it manually in the devshell09:32
ykronsok, I have tried first with devtool but I could not find my patches applied (it makes sense as they have to be updated ...) to have tried then with devshell to applied them manually ... will give a second try to devtool. Thanks09:35
ptsnevesthe patches applied can be seen by git log :)09:35
ptsnevesit is that simple09:35
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto09:35
ykronsbut current patch don't apply with the newer kernel so I guess have to reapply them manually09:38
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 250 seconds)09:39
ptsnevesyou can manually apply and then when the new patch is good you just commit it09:39
*** nemik <nemik!> has joined #yocto09:39
ptsnevesand git format-patch -n1 --full-index and you have a re-created patch09:40
qschulzgit am my.patch; resolve conflicts; git am --continue09:40
qschulzand then there's a devtool command to create the patches and add them to the recipe09:40
qschulzsomething like devtool finish with an option or something09:40
*** Schiller <Schiller!> has joined #yocto09:41
ykronsThanks. Should be ok now. I have already used devtool in the past but not to update patches.09:43
*** nemik <nemik!> has quit IRC (Ping timeout: 240 seconds)09:44
SchillerHello there. I have a controller-node and a worker-node. When i start the controller-container check the IP and create the worker in the worker-container like this buildbot-worker create-worker -r --umask=0o22 yocto-worker <controller-IP> some_name pass they connect fine. But when i try to give my controller container a static IP the09:44
Schillerworker-container seems to hang an is not able to connect even tho in twisted.log he tries to connect to the specific IP which the controller-container has. Can someone explain this behaviour?09:44
*** nemik <nemik!~nemik@> has joined #yocto09:44
TyakuIf I want to apply INHIBIT_SYSROOT_STRIP = "1" only to one recipe, I have to put "INHIBIT_SYSROOT_STRIP_pn-myrecipename = "1"" in local.conf ?09:50
TyakuI found it here: but not sure if it's correct.09:51
qschulzTyaku: or add it directly to the recipe via a bbappend09:51
*** kroon <kroon!> has quit IRC (Quit: Leaving)09:51
T_UNIX[m]<qschulz> "T_UNIX: where do you set..." <- I set them within the image's recipe.09:52
qschulzbut yes, if on old syntax _pn-myrecipenbame, if on new :pn-recupename09:52
*** ThomasRoos <ThomasRoos!> has quit IRC (Quit: Client closed)09:52
qschulzT_UNIX[m]: you cannot access IMAGE_FEATURES set in your image recipe from another recipe09:52
T_UNIX[m]And I check them wihtin i.e. qtbase09:52
qschulzan image recipe is a recipe, all limitations from package recipes apply09:52
qschulzT_UNIX[m]: what you want is DISTRO_FEATURES09:52
qschulzbecause it's set globally09:52
thomas_I have a function defined which is assigned to ROOTFS_POSTPROCESS_COMMAND (ROOTFS_POSTPROCESS_COMMAND += "tisdk_image_build; "). How I can force the bitbake to execute ROOTFS_POSTPROCESS_COMMAND?09:52
qschulzthomas_: it should be run by default IIRC09:53
thomas_I deleted the output of tisdk_image_build manually. So bitbake things this task is still up to date and do not execute it I guess. But calling bitbake -c do_rootfs does not work either09:53
T_UNIX[m]I want the same bounding set (systemd, etc.). That goes into my `distro.conf`. But I want one image to contain debug features while the other one shall not09:54
T_UNIX[m]one image shall then contain packages with some extra flags set, while the other image shall not09:54
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto09:55
T_UNIX[m]so I do not want to change DISTRO features. Kernel, Bootloader, Initmanager shall all stay the same.09:55
LetoThe2ndT_UNIX[m]: then you can append the distro. but the image cannot affect the things that go inside, just select.09:56
qschulzT_UNIX[m]: what you describe are two different distros in Yocto09:58
T_UNIX[m]Okay. So I need to build another distribution to have packages built differently?09:58
qschulzthat's a "policy"09:59
qschulz(building debug features for all packages)09:59
LetoThe2ndT_UNIX[m]: in a nutshell, yes. but the debug distro can essentially be just "original distro plus one flag"09:59
qschulzso it is a responsibility of distros09:59
qschulzthomas_: checkl with bitbake -e that your function is actually in ROOTFS_POSTPROCESS_COMMAND09:59
T_UNIX[m]yeah, that's what I got wrong. In my head building debug images would alter the packages. An since there are debug-pkgs, I figured, that should work for other modifications as well.10:00
LetoThe2ndT_UNIX[m]: but thats what i meant by "can select". because the image can select those additional dbg packages, which are essentially the symbols.10:01
T_UNIX[m]So `IMAGE_FEATURES` is basically merelly a convenience (implicit selection) around `IMAGE_INSTALL`?10:04
T_UNIX[m]anyway. Thanks for the clearification 🙂10:05
LetoThe2ndT_UNIX[m]: look at the image.bbclass and see for yourself.10:05
qschulzT_UNIX[m]: IMAGE_INSTALL is for packages. IMAGE_FEATURES is for anything, you can have switches anywhere in code if one feature is in that variable or not10:05
qschulzallows to have multiple images with the same features by using IMAGE_FEATURES from a distro configuration file10:06
T_UNIX[m]qschulz: This simple view is what I had in mind. But I didn't know that `IMAGE_FEATURES` could basically only modify `FILES` so to say.10:07
qschulzT_UNIX[m]: ?10:08
TyakuI try to put this 'INHIBIT_SYSROOT_STRIP:pn-cpc-daemon = "1"' in my local.conf then bitbake -c cleanall cpc-daemon and rebuild the target. But the generated executable is still stripped10:09
Tyaku/usr/bin/cpcd: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/, BuildID[sha1]=0de089ca21b39d94af966b912f009dd192f9a95a, for GNU/Linux 3.14.0, stripped10:09
qschulzTyaku: Are you sure it's INHIBIT_SYSROOT_STRIP that you want?10:10
T_UNIX[m]qschulz: `IMAGE_FEATURES` shall only modify what (i.e. debug symbols) get's build, right? It shall _not_ modify how something is built.10:10
T_UNIX[m]i.e. `CFLAGS`, etc.10:11
rburtonIMAGE_FEATURES doesn't modify how anything is built10:11
kayterina[m]Hello, I get a "pickle protocol " error when running bitbake for anything. I have removed the tmp directory. I am running through docker if it is important :
thomas_qschulz, I checked with bitbake -e that the function is really in ROOTFS_POSTPROCESS_COMMAND10:13
thomas_its there10:13
qschulzthomas_: you can run bitbake -c do_rootfs -f to check if your function is run10:14
qschulzthis will force the running of do_rootfs even if it already was run10:14
qschulzonce you've made sure your function is executed, then you can go a bit deeper and try to understand why it's not been rerun even though it changed10:15
*** pgowda_ <pgowda_!> has joined #yocto10:16
*** prabhakarlad <prabhakarlad!> has joined #yocto10:28
*** tomzy_0 <tomzy_0!> has joined #yocto10:30
*** Guest48 <Guest48!~Guest48@> has joined #yocto10:35
*** RobertBerger <RobertBerger!~rber|> has joined #yocto10:35
*** ptsneves <ptsneves!~ptsneves@2a00:f41:7046:92e2:5896:fa88:e59a:cd37> has quit IRC (Quit: Client closed)10:36
Guest48Hello, I am trying to build qemu with Yocto. I install all dependences, make a copy of poky from git, sourced oe-init-build-env  and start bitbake firstly without any updates of local.conf, than I make a changes just up to your video. I still get the same error message:10:37
Guest48> ERROR: Failed to spawn fakeroot worker to run poky/meta/recipes-kernel/linux-libc-headers/ [Errno 32] Broken pipe10:37
Guest48> I don’t have any idea how I can solve it. I was trying to find solutions on internet but I didn’t.10:37
Guest48I use honister branch10:37
Guest48Debian 10 as host machine10:38
Guest48I was following the youtube video and yocto documentation10:39
*** ptsneves <ptsneves!~ptsneves@2a00:f41:7046:92e2:fbf1:da89:c6c6:b764> has joined #yocto10:41
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Ping timeout: 252 seconds)10:42
qschulzptsneves: just sent a patch for the branch names to be displayed in the dropdown menu on the docs, thanks for asking10:43
Guest48sorry I don't understand what you mean10:48
kranzoGuest48: what video are you talking about? qschulz did not reply to you btw :)10:52
ptsnevesqschulz thank you!10:54
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 260 seconds)10:54
*** nemik <nemik!> has joined #yocto10:54
Guest48I just want to make bitbake core-image-minimal and I still get an error with fakeroot10:55
*** nemik <nemik!> has quit IRC (Ping timeout: 250 seconds)10:59
*** nemik <nemik!~nemik@> has joined #yocto10:59
*** Schiller <Schiller!> has quit IRC (Quit: Client closed)10:59
ykronsptsneves, qschulz : Thanks for your help. I finally get my first kernel patches updated ...11:07
ptsnevesykrons congrats11:07
ykronsQuestion: I have some kernel changes dispatched between patches (maybe 10) in the recipe and a forked kernel repository with maybe 50 commits. Is there any good reason not to move everything into the repo? I don't like to review modified patches. Diff of diff are breaking my brain and eyes11:12
qschulzykrons: if you can push to the forked kernel repo, better push there11:12
*** Guest48 <Guest48!~Guest48@> has quit IRC (Quit: Client closed)11:12
*** Guest48 <Guest48!~Guest48@> has joined #yocto11:14
thomas_I have a and a Can I somehow add all IMAGE_INSTALL entities from automatically to IMAGE_INSTALL from ? Without defining a packagegroup which is included by both?11:22
thomas_Both images using the same machine configuration11:23
ptsnevesthomas_ create an .inc file with the common stuff and include in both images11:24
ptsnevesi call it the distributive property of includes :D11:24
ptsneveswhen you want a common C in recipe A and B then AC+BC = C(A+B) where C is the include and A and B are recipes including C11:25
thomas_Basically what I want is an "sdk"-image, which has all packages of the "production"-image plus all the dev dbg and static-dev stuff11:25
ptsnevesby the way sdk image is not a target image and IMAGE_INSTALL is not valid there11:26
thomas_ptsneves, Yes thats clear. I was wondering if some IMAGE_INSTALL_iamge-a variable may exist11:26
ptsnevesthomas_ do not understand your last comment11:27
thomas_one moment11:27
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 248 seconds)11:29
*** nemik <nemik!> has joined #yocto11:29
*** tomzy_0 <tomzy_0!> has quit IRC (Quit: Client closed)11:32
*** nemik <nemik!> has quit IRC (Ping timeout: 256 seconds)11:34
*** nemik <nemik!~nemik@> has joined #yocto11:34
thomas_ptsneves, I deal with this:    and this
thomas_To generate an SDK which should include a targetfs which should be equal as possible with my actual production image11:35
*** Schiller <Schiller!> has joined #yocto11:36
thomas_Because image -c do_populate_sdk is not supported from arago it seems11:36
ptsnevesyeah it is not supported because they are doing something very creative. They are creating an image with host tools for the target?11:37
thomas_What you mean by hsot tools for the target?11:38
ptsnevesi have no experience with TI layers, but this is not very yocto specific and i never worked with TI layers so I cannot help. The issue is they confuse image with SDK and they are not the same in yocto. I think you are in for a ride11:38
ptsnevesIMAGE_INSTALL generates images for a target11:38
ptsnevesSDK_INSTALL generates sdk packages for SDK_MACHINE11:39
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 250 seconds)11:39
thomas_Yeah I know - I sit between the chairs11:39
ptsneves:)  i suggest you ask in the TI forums11:39
*** nemik <nemik!~nemik@> has joined #yocto11:39
thomas_:) Sure, Ive done that. But it will take weeks if I ever get an answer which redirects me either to yocto or arago "community"11:40
thomas_But thanks for the IMAGE_INSTALL and SDK_INSTALL definition. The problem is, I havn't understand the bigger picture of arago11:41
thomas_And I do know less about generating an SDK the normal yocto way to bridge that knowledge gap11:42
thomas_So sdk packages are normally just the cross-toolchains right?11:43
thomas_I'll go with that include solution.. :D11:45
ptsneveshey Tomas, sorry not always available. The deal is you have an SDK_MACHINE set (the machine your sdk is supposed to be deployed, normally x86-64) and the MACHINE which represents your target.11:49
ptsnevesYour sdk contains cross toolchain and cross libraries. The goal being you can compile programs using your sdk, outside yocto.11:49
ptsneveswhat TI, has is some creation of their own and i don't understand it without deep diving in it, but that is work that is likely paid :)11:49
ptsnevesqschulz do we have any page of Yocto consultants?11:50
kranzoptsneves: ?11:51
*** kranzo <kranzo!> has quit IRC (Quit: Client closed)11:51
qschulzptsneves: first result on your favorite search engine with "yocto consultants" :)11:52
*** kranzo <kranzo!> has joined #yocto11:52
kranzoor did i misuderstand the question?11:52
ptsneveskranzo not at all. Perfect! I did not know of such page. The yocto project has a really nice communication11:53
*** Schiller <Schiller!> has quit IRC (Quit: Client closed)12:00
thomas_ptsneves, thank you very much ;) I don't wanna blame anyone. I think software engineers at TI are also very busy and have limited time for customer support. Just the documentation about arago could a bit more...12:01
*** kranzo <kranzo!> has quit IRC (Quit: Client closed)12:02
*** kranzo <kranzo!> has joined #yocto12:05
*** Guest48 <Guest48!~Guest48@> has quit IRC (Quit: Client closed)12:11
*** Guest48 <Guest48!~Guest48@> has joined #yocto12:11
*** ptsneves <ptsneves!~ptsneves@2a00:f41:7046:92e2:fbf1:da89:c6c6:b764> has quit IRC (Quit: Client closed)12:11
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)12:13
*** ptsneves <ptsneves!~ptsneves@2a00:f41:7046:92e2:fbf1:da89:c6c6:b764> has joined #yocto12:13
*** zyga-mbp <zyga-mbp!> has quit IRC (Quit: Textual IRC Client:
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 276 seconds)12:29
*** nemik <nemik!> has joined #yocto12:29
*** nemik <nemik!> has quit IRC (Ping timeout: 252 seconds)12:34
*** nemik <nemik!~nemik@> has joined #yocto12:34
thomas_ptsneves, what about TOOLCHAIN_TARGET_TASK and TOOLCHAIN_HOST_TASK ? Are packages that are added to that variables deployd either on MACHINE / SDK_MACHINE ?12:41
*** Schiller <Schiller!> has joined #yocto12:41
*** zyga-mbp <zyga-mbp!> has joined #yocto12:44
kranzojust nativesdk- versions of them12:45
kranzoadded them to get a working sdk but nor esdk wont build properly. :/12:46
LetoThe2ndzeddii: have you ever run into failing on a missing singletask.lock for a go-based recipe?12:47
thomas_kranzo, I just need a working SDK - i pray for it12:49
kranzothomas_: ah my brain mixed your thread into my problem:D   need another coffee12:50
thomas_I've added a package to TOOLCHAIN_TARGET_TASK. But it seems not to get deployed in the target rootfs. How do I find out why? I've checked with bitbake -e the content of TOOLCHAIN_TARGET_TASK and it shows up there.12:51
thomas_kranzo, im sorry :)12:51
kranzodid you enable BUILDHISTORY?12:53
thomas_yes, i have a buildhistory folder12:55
zeddiiLetoThe2nd: I can't say that I have.  strange that it is being packaged in one, or otherwise influencing the output. Is the recipe doing something 'strange' that might be capturing the transient lock file ?12:55
ptsnevesthomas_ the variables you mention are used to build an SDK. YOu build an SDK with populate_sdk task.There are no rootfs for sdks12:56
thomas_ptsneves, How do I call the cross libraries of my SDK? I thought its the rootfs of the SDK12:57
ptsnevesi think you do not need to do any fancy thing. the cross toolchain automatically sets the sysroot of your cross compilers to the location of your target libraries12:58
LetoThe2ndzeddii: what might be a strange thing? the only thing that i know of noteworthy that its cgo.12:58
thomas_In my world, an SDK consists of two parts. First, the toolchain I need to build against the target. And second I need all the libs/headers for that target12:59
kranzothomas_: both will be in the sdk13:00
zeddiiLetoThe2nd:  There have been builds in the past that copied/captured files and / or checksum'd the source dir, and then incorporated that hash into the binaries. That could pick up a transient file and cause an issue like that. but if this is calling go/cgo directly in the recipe, and not using the packages scripts/Makefile, that definitely won't be happening here.13:01
kranzoyou can check for installed files in the buildhistory folder13:01
*** tomzy_0 <tomzy_0!> has joined #yocto13:01
thomas_Okay lets say I have a package foobar, which is a library. I install foobar on my normal "production"-image. Now I want to create an app which depends on foobar. I need now an SDK which includes the foobar-lib and also the foobar-header at /usr/lib and /usr/include13:02
LetoThe2ndzeddii: hmmm that might be misworded then by me. the error specifically said that singletask.lock was missing. the reprodicible part is only that it is being searched for from reproducible.py13:02
zeddiiaha. I see.13:03
thomas_And the folder, whereas the header and libray are placed in to build my app against it, I called that "rootfs" of the SDK. Because it has the same structure like the normal production-image13:03
thomas_Is that wrong?13:04
zeddiiright, there should be no randomness there.13:04
kranzothats an installed sdk so i think you are right :)13:07
qschulzthomas_: it's called sysroot when not on the target usually13:08
thomas_ohhh ok sysroot. Sorry for the confusion13:09
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 256 seconds)13:09
thomas_I rephrase my question: Should a package. which I added to the TOOLCHAIN_TARGET_TASK list, show up in sysroot?13:10
thomas_In the normal SDK13:10
*** GuestNew <GuestNew!~GuestNew@> has joined #yocto13:11
*** ilunev <ilunev!~koolkhel@> has joined #yocto13:13
GuestNewAfter updating to kirkstone, i got the issue during boot "module has no symbols (stripped?)" I'm not self confident with Yocto to understand what I have to configure fix that ? (I'm FPGA developer and i don't know many thing about linux drivers) any help ?13:13
thomas_ahh perfect. thank you kranzo !!! Now I can go from here and search for the reason why it doesnt show up :D13:13
*** nemik <nemik!~nemik@> has joined #yocto13:14
*** hcg <hcg!~hcg@> has joined #yocto13:17
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto13:18
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 260 seconds)13:19
*** nemik <nemik!~nemik@> has joined #yocto13:24
*** ptsneves <ptsneves!~ptsneves@2a00:f41:7046:92e2:fbf1:da89:c6c6:b764> has quit IRC (Quit: Client closed)13:29
*** sakoman <sakoman!> has joined #yocto13:53
*** ptsneves <ptsneves!~ptsneves@2a00:f41:7046:92e2:2cd:5452:22da:207b> has joined #yocto14:01
*** Guest48 <Guest48!~Guest48@> has quit IRC (Quit: Client closed)14:02
thomas_holy shit! I think I've got it!!!! Lol - it took me nearly a full week! A SDK for my custom image based on arago!14:18
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 248 seconds)14:19
thomas_Big dopamin release in my brain!14:19
*** nemik <nemik!> has joined #yocto14:19
TyakuI found the function that cause my "buffer overflow" error !!! (But I don't really understand because how this function is implemented is not clearly explained). The code calls realpath(x, y) where x is a char * = "/dev/serial/by-id/usb-Silicon_Labs_J-Link_Pro_OB_000000123456-if00" (terminated by \0) and y is a 256 bytes buffer. After increasing the size of Y from 128 to 4096 I don't have buffer overflow,14:20
Tyakubut after the function execution y contains "/dev/ttyACM0".14:20
*** sashko <sashko!> has quit IRC (Ping timeout: 240 seconds)14:20
TyakuSo I think, internally this function do something like "memset()" on the entire size of the expected buffer [...]14:21
kranzothomas_: gz14:21
kranzomy esdk is still not compiling because basehash changes and i'm relay confused why14:22
*** nemik <nemik!> has quit IRC (Ping timeout: 248 seconds)14:24
*** nemik <nemik!~nemik@> has joined #yocto14:24
*** GuestNew <GuestNew!~GuestNew@> has quit IRC (Quit: Client closed)14:31
LetoThe2ndarmpit: sorry for misreading the date. my bad.14:32
TyakuWhen I debug cpc-daemon (build with the yocto toolhchain) I don't have "buffer overflow". I filled the y parameter with caracter "0xaa", and I see that only the first bytes are changed by the function.14:33
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 256 seconds)14:34
*** nemik <nemik!> has joined #yocto14:34
TyakuBut I think when bitbake build cpc-daemon, this function works differently14:34
Tyakuis it possible to see how is implemented "realpath()"  ?14:34
*** ptsneves <ptsneves!~ptsneves@2a00:f41:7046:92e2:2cd:5452:22da:207b> has quit IRC (Quit: Client closed)14:34
*** nemik <nemik!> has quit IRC (Ping timeout: 256 seconds)14:38
*** nemik <nemik!~nemik@> has joined #yocto14:39
kranzocan someone give me a hint how i can track down basehash changes?14:40
*** F_Adrian <F_Adrian!~F_Adrian@> has joined #yocto14:42
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)14:45
kanavinRP, F_Adrian and I would like to talk about eSDK plans when you have a bit of time, would really appreciate your input.14:46
*** Schiller <Schiller!> has quit IRC (Ping timeout: 252 seconds)14:48
*** otavio <otavio!> has quit IRC (Ping timeout: 250 seconds)14:48
*** otavio <otavio!> has joined #yocto14:50
thomas_kranzo, i had the same issue: My root problem was the git auth stuff. Some recipes used git to read git hashes which failed when the user "root" did it14:51
*** lexano <lexano!~lexano@> has quit IRC (Ping timeout: 246 seconds)14:51
*** rber|res <rber|res!~rber|> has quit IRC (Ping timeout: 248 seconds)14:52
*** RobertBerger <RobertBerger!~rber|> has quit IRC (Ping timeout: 248 seconds)14:53
thomas_This causes that by reevaluation from normal user the "task metadata" has been changed which resulted in changed basehashes14:53
kranzoseems clear but how did you find that? i'm stuck because i cant even check what is happaning14:54
thomas_Yocto printed a command which I used to track this down - I try to find it again14:55
thomas_kranzo, here you go:
thomas_bitbake os-release -cdo_compile -Snone14:55
thomas_bitbake os-release -cdo_compile -Sprintdiff14:55
kranzoah sadly the output is empty all the time :/14:56
*** tgamblin <tgamblin!> has quit IRC (Ping timeout: 248 seconds)14:56
thomas_Sorry. In my case it even printed the variable that has been changed14:56
*** tomzy_0 <tomzy_0!> has quit IRC (Quit: Client closed)15:00
*** kranzo <kranzo!> has quit IRC (Quit: Client closed)15:01
*** thomas_ <thomas_!> has quit IRC (Ping timeout: 248 seconds)15:03
*** kranzo <kranzo!> has joined #yocto15:03
*** lexano <lexano!~lexano@> has joined #yocto15:03
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 256 seconds)15:09
*** nemik <nemik!> has joined #yocto15:09
*** ptsneves <ptsneves!~ptsneves@2a00:f41:7046:92e2:5f6d:592d:4489:e46f> has joined #yocto15:11
*** Tyaku <Tyaku!> has quit IRC (Quit: Lost terminal)15:13
*** nemik <nemik!> has quit IRC (Ping timeout: 260 seconds)15:13
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)15:14
*** nemik <nemik!~nemik@> has joined #yocto15:14
*** hcg <hcg!~hcg@> has quit IRC (Quit: Client closed)15:20
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto15:28
*** rber|res <rber|res!~rber|> has joined #yocto15:35
*** RobertBerger <RobertBerger!~rber|> has joined #yocto15:36
*** cmd <cmd!~cmd@user/cmd> has quit IRC (Ping timeout: 240 seconds)15:38
*** rber|res <rber|res!~rber|> has quit IRC (Remote host closed the connection)15:39
*** RobertBerger <RobertBerger!~rber|> has quit IRC (Remote host closed the connection)15:39
*** kranzo <kranzo!> has quit IRC (Quit: Client closed)15:41
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:b43d:613b:a6e0:1a49> has quit IRC (Remote host closed the connection)15:41
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:b43d:613b:a6e0:1a49> has joined #yocto15:41
*** ilunev <ilunev!~koolkhel@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)15:41
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)15:45
rburtonRP: so interestingly, fakeroot doesn't have the problem that pseudo does.  "fakeroot git status" doesn't moan that the repo is owned by another user...16:02
*** ilunev <ilunev!~koolkhel@> has joined #yocto16:07
*** stanf <stanf!> has joined #yocto16:09
*** stanf27 <stanf27!> has joined #yocto16:11
*** stanf <stanf!> has left #yocto16:12
*** stanf27 <stanf27!> has left #yocto16:13
*** stanf <stanf!> has joined #yocto16:14
rburtonoh, fakeroot changes ownership of files it reads too!16:15
rburtonthat's ... horrid16:15
rburton$ ls -l Makefile16:15
rburton-rw-rw-r-- 1 ross ross 108341 May  5 17:13 Makefile16:15
rburton$ fakeroot ls -l Makefile16:15
rburton-rw-rw-r-- 1 root root 108341 May  5 17:13 Makefile16:15
stanfDoes anyone get issue using OE gitpkgv.bbclass for versioning? Seems broken due to recent update
*** starblue <starblue!> has quit IRC (Ping timeout: 276 seconds)16:18
*** starblue <starblue!> has joined #yocto16:19
ptsnevesHey i am having randome mismatches with kernel module versions. There is a new flag CONFIG_GCC_PLUGIN_RANDSTRUCT enabled by default in newer kernels which enables randomization struct addresses. This randomization is based on a seed. In dunfell this seed is generated on the do_compile, copied to the work-shared CONFIG_GCC_PLUGIN_RANDSTRUCT by16:21
ptsneveskernel.bbclass:do_work_shared and then make-mod-scripts overwrites that value16:21
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 260 seconds)16:24
*** nemik <nemik!> has joined #yocto16:24
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:24
ptsnevesHere i show a prefunc of make-mod-scripts:do_configure and a postfunc printing the16:25
ptsnevesWARNING: make-mod-scripts-1.0-r0 do_configure: /opt/mydistro/build/tmp/work-shared/mydevice-gw20/kernel-build-artifacts:#define RANDSTRUCT_HASHED_SEED "bc0596425ac4d06d718fe2e559432c161e08cd130fd6fcc5cc062b0b3c5f0a4c"16:25
ptsnevesWARNING: make-mod-scripts-1.0-r0 do_configure: /opt/mydistro/build/tmp/work-shared/mydevice-gw20/kernel-build-artifacts:#define RANDSTRUCT_HASHED_SEED "8625edcb4b8646b674796c93c1e2f3be55184e1b86012341f31fbc6a3124f446"16:25
ptsnevesthese are prints of ${STAGING_KERNEL_BUILDDIR}/include/generated/randomize_layout_hash.h16:26
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 246 seconds)16:28
*** nemik <nemik!> has quit IRC (Ping timeout: 260 seconds)16:28
mario-goulartHi.  In scenarios where BBMULTICONFIG is set, is expected that events like BuildCompleted are fired multiple times?16:29
*** nemik <nemik!~nemik@> has joined #yocto16:30
*** camus <camus!~Instantbi@2409:8a1e:9112:6900:50de:4772:36f2:d662> has quit IRC (Ping timeout: 260 seconds)16:31
*** JPEW <JPEW!> has quit IRC (Ping timeout: 246 seconds)16:33
*** JPEW <JPEW!> has joined #yocto16:36
*** lexano <lexano!~lexano@> has quit IRC (Ping timeout: 256 seconds)16:36
*** lexano <lexano!~lexano@> has joined #yocto16:49
*** mckoan is now known as mckoan|away16:53
*** ptsneves <ptsneves!~ptsneves@2a00:f41:7046:92e2:5f6d:592d:4489:e46f> has quit IRC (Quit: Client closed)16:53
*** stanf <stanf!> has quit IRC (Quit: Client closed)17:00
*** stanf <stanf!> has joined #yocto17:02
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 260 seconds)17:15
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 246 seconds)17:28
*** nemik <nemik!> has joined #yocto17:28
*** otavio <otavio!> has quit IRC (Ping timeout: 246 seconds)17:29
*** nemik <nemik!> has quit IRC (Ping timeout: 246 seconds)17:33
*** nemik <nemik!~nemik@> has joined #yocto17:33
*** otavio <otavio!> has joined #yocto17:36
*** otavio <otavio!> has quit IRC (Ping timeout: 248 seconds)17:42
*** pgowda_ <pgowda_!> has quit IRC (Quit: Connection closed for inactivity)17:43
*** stanf <stanf!> has quit IRC (Quit: Client closed)17:43
*** otavio <otavio!~otavio@> has joined #yocto17:49
*** otavio <otavio!~otavio@> has quit IRC (Ping timeout: 248 seconds)17:55
*** otavio <otavio!> has joined #yocto17:56
JPEWmario-goulart: yes17:57
*** zyga-mbp <zyga-mbp!> has quit IRC (Read error: Connection reset by peer)17:58
*** zyga <zyga!> has joined #yocto17:58
mario-goulartJPEW: thanks!18:02
*** bps <bps!> has joined #yocto18:04
*** florian_kc <florian_kc!> has joined #yocto18:10
sveinseIs there a way to mute the warning "Submodule included by ... refers to relative ssh reference References may fail if not absolute."? This way of specifying repo references is very common, encouraged even, by github and bitbucket, so many repos are littered with this subrepo references, leading to a storm of false positive warnings in the build logs.18:22
JPEWsveinse: That seems like a false positive on the warning to me18:27
JPEWfray: ^^ ?18:27
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 260 seconds)18:29
sveinseits this warning:
*** GillesM <GillesM!> has joined #yocto18:33
*** GillesM <GillesM!> has quit IRC (Remote host closed the connection)18:33
sveinseIt seems its the syntax `` and the lack of `:/` in the url that triggers the warning18:33
sveinseThe fix is to use the full (proper?) syntax `ssh:\\` but I'd argue that that format isn't that widely used in git urls.18:36
JPEWsveinse: Ya. I'm not sure what usage pattern fray was attempting to check for there; might wait to see if any insight is given18:36
JPEWMight be able to update the check if we know qhat a "bad" URL is supposed to be18:37
*** kergoth <kergoth!> has left #yocto18:47
*** kergoth <kergoth!> has joined #yocto18:47
*** prabhakarlad <prabhakarlad!> has joined #yocto19:19
*** wyre <wyre!~wyre@user/wyre> has quit IRC (Quit: ZNC 1.8.2 -
*** wyre <wyre!~wyre@user/wyre> has joined #yocto19:36
*** turkeykittin <turkeykittin!> has joined #yocto19:37
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)19:52
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 246 seconds)19:54
*** nemik <nemik!> has joined #yocto19:54
*** nemik <nemik!> has quit IRC (Ping timeout: 256 seconds)19:58
*** nemik <nemik!~nemik@> has joined #yocto19:59
sveinseWhat does the error "An allarch packagegroup shouldn't depend on packages which are dynamically renamed (lksctp-tools to libsctp1)" mean? As in, what change do I need to make in the packagegroup? Rename rdep to libsctp1 as it sais in the error?19:59
*** olani <olani!~olani@> has quit IRC (Remote host closed the connection)20:03
sveinseFound this "If you run into this issue you either need to remove the dependency from the packagegroup or mark the packagegroup as tune specific" here
neverpanicsveinse: This message is to protect you, really. You seem to have what's called "debian renaming" enabled, where packages that only contain libraries are renamed to <libraryname><soversion>20:06
sveinseWhat I'm understanding from this is that I need to extract all the "dynamically renamed" packages into a separate tune specific packagegroups?20:06
neverpanicIf you didn't have this warning and added a dependency, but then updated the library so that its soname (and thus generated package name) changes, the packagegroup wouldn't be rebuilt, and thus be broken.20:06
neverpanicEither that, or you just need to make the packagegroup not allarch. The overhead of doing the latter is probably negligible20:07
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 256 seconds)20:09
*** nemik <nemik!> has joined #yocto20:09
*** nemik <nemik!> has quit IRC (Ping timeout: 248 seconds)20:13
*** nemik <nemik!~nemik@> has joined #yocto20:14
*** mihai <mihai!~mihai@user/mihai> has quit IRC (Quit: Leaving)20:15
RPkanavin: quite the series, thanks! :)20:19
*** gsalazar_ <gsalazar_!> has quit IRC (Ping timeout: 248 seconds)20:30
kanavinRP: cheers :) and I prefer to not use the word 'bomb' for the time being.20:34
kanavinit had produced a completely green a-full too last night, I was glad enough to see that on my smartphone, that I actually jumped out of bed to hit git send-email, then fall back into bed20:38
*** olani <olani!~olani@> has joined #yocto20:38
kanavinwork from home can mix up 'work' and 'home' like that20:38
RPkanavin: I was wondering about the timing! :)20:39
RPkanavin: it is nice to see some of the patch counts falling20:39
kanavinRP: yes, I have a (bad) habit of checking my a-fulls from my mobile. I wish buildbot had a 'blind mode' where you can't see builds in progress :)20:40
*** GillesM <GillesM!> has joined #yocto20:40
*** GillesM <GillesM!> has quit IRC (Client Quit)20:40
kanavinonly the final verdict!20:40
mcfrisksveinse: saw that today too, and marked the package group tune specific as the poky side commit says20:41
kanavinRP: I'll try to carry on with upstreaming or otherwise streamlining the pending patches20:41
RPkanavin: I do tend to watch my builds too! :)20:45
RPkanavin: I'm still hoping we can see a chunk of libtool ones merge and the new gcc release cleans up a few there too20:45
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 260 seconds)20:46
*** bps <bps!> has joined #yocto20:49
*** florian_kc <florian_kc!> has joined #yocto21:15
*** Rolle6 <Rolle6!> has joined #yocto21:19
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 260 seconds)21:20
*** nemik <nemik!~nemik@> has joined #yocto21:20
Rolle6I'll try to formulate my question though I am very new to Yocto. I have two "top-level" bb classes, one that builds the SDK, full image etc, and one that builds the initramfs (expressed as to .bb files).  The initramfs bb file basically inherits from core-image. The initramfs needs to be used later when i build applications with the sdk (it will21:26
Rolle6be baked into a fitImage in a later stage when I have access to more dtsi files), so I I would like to distribute the initramfs with the SDK. I cannot just point to the bb file with TOOLCHAIN_TARGET_TASK (I assume as it has not install stage etc?) How can I include it in my SDK?21:26
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 248 seconds)21:30
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 276 seconds)21:39
*** nemik <nemik!> has joined #yocto21:39
*** nemik <nemik!> has quit IRC (Ping timeout: 252 seconds)21:44
*** nemik <nemik!~nemik@> has joined #yocto21:44
*** rhowell <rhowell!~rhowell@2605:a601:a937:b200:29cb:4acd:a4b:803d> has joined #yocto21:49
rhowellIs it possible to force change the BBFILE_PRIORITY of a single recipe in my layer? I have a do_install_append() that needs to be highest priority so I can override stuff.  But my code is ending up in the middle of the final do_install() function.   My layer priority is set to "6" and the other conflicting layer is set to "8".  I have tried21:54
rhowellBBFILE_PRIORITY = "10" in the recipe itself, but the it doesn't seem to have an effect. is there a way to force set the priority for a single recipe or can I only set it at the layer level?21:54
sveinseI thought I had all allarch packagegroups under control, but then one in official meta-qt5 turns up in nativesdk-packagegroup-qt5-toolchain-host :( Apparently it does not help to bbappend in PACKAGE_ARCH = "${TUNE_PKGARCH}" either22:01
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)22:03
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto22:04
*** F_Adrian <F_Adrian!~F_Adrian@> has quit IRC (Ping timeout: 246 seconds)22:06
*** Rolle6 <Rolle6!> has quit IRC (Quit: Client closed)22:14
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 260 seconds)22:26
*** florian_kc <florian_kc!> has joined #yocto22:26
*** dev1990 <dev1990!> has quit IRC (Ping timeout: 240 seconds)23:05
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 260 seconds)23:19
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 276 seconds)23:20
*** nemik <nemik!~nemik@> has joined #yocto23:20
*** barometz <barometz!> has quit IRC (Ping timeout: 256 seconds)23:32
*** barometz <barometz!> has joined #yocto23:34
*** kevinrowland <kevinrowland!> has joined #yocto23:34

Generated by 2.17.2 by Marius Gedminas - find it at!