Friday, 2024-01-19

*** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@> has joined #yocto00:01
*** marka <marka!> has joined #yocto00:01
*** OnkelUll_ <OnkelUll_!> has joined #yocto00:02
*** smooge- <smooge-!smooge@centos/qa/smooge> has joined #yocto00:02
*** kpo_ <kpo_!> has joined #yocto00:03
*** svuorela_ <svuorela_!> has joined #yocto00:05
*** asrieldreemurr <asrieldreemurr!~asriel@user/asriel> has joined #yocto00:05
*** yudjinn_ <yudjinn_!> has joined #yocto00:09
*** kpo <kpo!> has quit IRC (*.net *.split)00:09
*** khazakar <khazakar!> has quit IRC (*.net *.split)00:09
*** geoffhp <geoffhp!> has quit IRC (*.net *.split)00:09
*** tlwoerner <tlwoerner!> has quit IRC (*.net *.split)00:09
*** OnkelUlla <OnkelUlla!> has quit IRC (*.net *.split)00:09
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC (*.net *.split)00:09
*** sotaoverride <sotaoverride!~ctraven@> has quit IRC (*.net *.split)00:09
*** Saur <Saur!> has quit IRC (*.net *.split)00:09
*** yudjinn <yudjinn!> has quit IRC (*.net *.split)00:09
*** asriel <asriel!~asriel@user/asriel> has quit IRC (*.net *.split)00:09
*** svuorela <svuorela!> has quit IRC (*.net *.split)00:09
*** TundraMan <TundraMan!> has quit IRC (*.net *.split)00:09
*** dvergatal <dvergatal!> has quit IRC (*.net *.split)00:09
*** smooge <smooge!smooge@centos/qa/smooge> has quit IRC (*.net *.split)00:09
*** _whitelogger <_whitelogger!> has quit IRC (*.net *.split)00:09
*** smooge- is now known as smooge00:09
*** dvergatal <dvergatal!> has joined #yocto00:10
*** _whitelogger_ <_whitelogger_!> has joined #yocto00:10
*** ctraven <ctraven!~ctraven@> has joined #yocto00:10
*** Saur <Saur!> has joined #yocto00:17
*** khazakar <khazakar!> has joined #yocto00:22
*** kpo <kpo!> has joined #yocto00:52
*** kpo_ <kpo_!> has quit IRC (Ping timeout: 264 seconds)00:53
*** marka <marka!> has quit IRC (Quit: ZNC 1.8.2 -
*** marka <marka!> has joined #yocto01:34
dvergatalRP: one additional question because I have found something else
dvergatalRP: does it mean that if I will delete the tmp directory I also need to delete sstate-cache?01:39
*** lexano <lexano!~lexano@> has quit IRC (Ping timeout: 276 seconds)01:59
*** davidinux <davidinux!> has quit IRC (Ping timeout: 264 seconds)02:04
*** davidinux <davidinux!> has joined #yocto02:05
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)02:16
*** Saur_Home22 <Saur_Home22!> has quit IRC (Quit: Client closed)02:19
*** Saur_Home22 <Saur_Home22!> has joined #yocto02:19
*** kpo <kpo!> has quit IRC (Remote host closed the connection)02:39
*** xmn <xmn!> has quit IRC (Ping timeout: 276 seconds)03:13
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)03:17
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto03:18
*** jclsn <jclsn!~jclsn@2a04:4540:6514:1500:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 256 seconds)03:18
*** jclsn <jclsn!~jclsn@2a04:4540:6511:d100:2ce:39ff:fecf:efcd> has joined #yocto03:20
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)03:20
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto03:21
*** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Read error: Connection reset by peer)03:32
*** khem <khem!> has quit IRC (Quit: Connection closed for inactivity)03:33
*** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto03:34
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Remote host closed the connection)03:37
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto03:37
*** khem <khem!> has joined #yocto05:02
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)05:21
*** camus <camus!~Instantbi@> has joined #yocto05:22
*** OnkelUll_ is now known as OnkelUlla05:42
*** Thorn_ <Thorn_!~Thorn@2001:8a0:dfe1:a200:6415:2cb2:9200:20cb> has joined #yocto06:31
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 260 seconds)06:32
*** jmd <jmd!~user@2001:a61:2b90:5c01:6de1:a363:1092:21f> has joined #yocto06:58
*** jmd <jmd!~user@2001:a61:2b90:5c01:6de1:a363:1092:21f> has quit IRC (Remote host closed the connection)07:13
*** linfax <linfax!> has joined #yocto07:19
*** rob_w <rob_w!> has joined #yocto07:29
*** mckoan|away is now known as mckoan07:34
LetoThe2ndyo dudX07:48
mckoanLetoThe2nd: hey07:54
*** Kubu_work <Kubu_work!> has joined #yocto07:55
Xogiumhiya good people07:57
*** zpfvo <zpfvo!> has joined #yocto07:57
*** Tyaku <Tyaku!> has joined #yocto08:11
*** thomas_34 <thomas_34!> has joined #yocto08:11
thomas_34Good morning guys. Is there somewhere in yocto a tool, or some statistics which record the build-time of a recipe?08:12
JaMathomas_34: see buildstats.bbclass08:16
*** vladest <vladest!> has quit IRC (Ping timeout: 264 seconds)08:16
thomas_34thanks JaMa :)08:16
TyakuHello, I have a sysctl question about priority of "DEV" or "all" configuration. I found on a forum that this is dependent on the kernel that's why I am asking here. In my yocto system it seems that if /proc/sys/net/ipv6/conf/all/forwarding is 1, then even if I set /proc/sys/net/ipv6/conf/eth0/forwarding at 0, the forwarding keep active for eth0. The reverse is also true, If I set all at "0" and eth008:17
Tyakuforwarding to "1", the forwarding is disabled for eth0.08:17
*** Thorn_ <Thorn_!~Thorn@2001:8a0:dfe1:a200:6415:2cb2:9200:20cb> has quit IRC (Quit: Easy as 3.14159265358979323846...)08:17
TyakuIn my case I have two physical interfaces (eth0, mlan0) and one internal (wpan0 for Thread border router). I want to enable the forwarding on wpan0+{eth0 **or** mlan0: depending on the interface behing used, with a preference if the two interfaces are used)08:18
RPdvergatal: no, sstate-cache can be saved08:22
TyakuIn over terms: I see that only the "all" configuration has effect, interfaces configuration has no effect.08:28
TyakuIs this normal ?08:28
*** vladest <vladest!~Thunderbi@> has joined #yocto08:41
dvergatalRP: meaning that I can save sstate-cache and rebuild from it with cleaned tmp?08:43
dvergatalRP: I'm sorry to ask such questions because I'm a little bit confused right now due to this documentation statement08:44
dvergatalRP: and I always thought that I can build with cleaned tmp and sstate-cache than I can remove tmp and rebuild just from sstate08:45
dvergatalRP: correct me if I'm wrong08:50
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:55
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 264 seconds)08:55
*** florian <florian!> has joined #yocto09:04
*** zpfvo <zpfvo!> has joined #yocto09:09
RPdvergatal: that should work, yes09:22
RPTyaku: that is more of a networking question than I'm able to answer I'm afraid09:22
dvergatalRP: OK so the documentation has a bug than:P09:23
dvergatalRP: nevertheless I wanted to give you some more details on the issue and I was not able to, sorry for that, maybe I will be able to do that today09:25
RPdvergatal: it needs to be clarified, yes as it is unclear. Could you open a bug or send a patch please?09:28
dvergatalRP: OK09:33
*** alessioigor <alessioigor!~alessioig@> has joined #yocto09:43
*** Saur_Home22 <Saur_Home22!> has quit IRC (Quit: Client closed)09:59
*** Tyaku <Tyaku!> has quit IRC (Quit: Lost terminal)10:00
*** Saur_Home22 <Saur_Home22!> has joined #yocto10:00
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto10:02
*** alperak <alperak!~alperak@> has joined #yocto10:05
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)10:22
*** prabhakarlad <prabhakarlad!~prabhakar@> has quit IRC (Ping timeout: 250 seconds)10:25
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto10:28
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)10:33
*** alessioigor <alessioigor!~alessioig@> has joined #yocto10:34
dvergatalRP: OK to clarify as you mentioned yesterday "21:29 < RP> dvergatal: it depends what is being installed. The postinsts will only be present for the things which get re-installed from sstate" does this mean that not all scripts will be there and thus fixme in staging.bbclass has not all dependencies?10:34
*** Saur_Home22 <Saur_Home22!> has quit IRC (Quit: Client closed)10:42
*** Saur_Home22 <Saur_Home22!> has joined #yocto10:42
*** florian__ <florian__!> has joined #yocto10:44
rburtonthomas_34: look up "why is my build so slow" on youtube10:49
RPdvergatal: You're asking me to be specific about very vague things. Sstate dependencies will be installed as needed. If for example you're building a rootfs, target do_populate_sysroot would be skipped in most cases10:53
RPnative do_populate_sysroot would be installed for things needed by the rootfs.10:53
dvergatalRP: I'm asking about do_populate_sysroot_setscene10:54
*** camus1 <camus1!~Instantbi@> has joined #yocto10:55
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)10:57
*** camus1 is now known as camus10:57
dvergatalRP: for some reason during this function run fixme does not containe all postinst scripts10:57
RPdvergatal: I would have thought that the do_populate_sysroot_setscene (which is what the error you pasted is from) should have the USERADD_DEPENDS added and as such, the postinst should be present11:05
RPdvergatal: that said, I can see you're using all kinds of patches I have no idea about and are doing this on a version that I hasn't been updated for the USERADD_DEPENDS code11:06
RPdvergatal: as I said before, we really need reproducible test cases against master which we can then debug and fix.11:08
dvergatalRP: just these 3 from you and one I have posted on bugzilla and this all is on kirkstone the only thing that differs regarding the test given in patch is that in my case my package depends with USERADD_DEPENDS on more than one package and also the dependency chain looks like that A depends on B and C and B also depends on C11:12
RPdvergatal: I'm not spending all of my time with this forefront in my mind. "these 3 from you" could be all kinds of things. I'm sorry but I can't help you with kirkstone at all11:16
RPI'm drawing a line on that, I'd had enough, sorry11:16
dvergatalRP: sure I will post this use case on this bug11:16
dvergatalwhere you have stated the commits11:17
dvergatalRP: but first I will switch for a test to newst master to check if it also occur there11:21
*** alperak <alperak!~alperak@> has quit IRC (Quit: Client closed)11:34
*** alperak <alperak!~alperak@> has joined #yocto11:35
*** Saur_Home22 <Saur_Home22!> has quit IRC (Quit: Client closed)11:44
*** Saur_Home22 <Saur_Home22!> has joined #yocto11:44
*** tleb <tleb!6dbdd9ebc9@2a03:6000:1812:100::10cf> has quit IRC (Ping timeout: 260 seconds)11:50
*** jonesv <jonesv!e7e4272e85@2a03:6000:1812:100::10b5> has quit IRC (Ping timeout: 260 seconds)11:52
*** raghavgururajan <raghavgururajan!ea769b8000@user/raghavgururajan> has quit IRC (Ping timeout: 268 seconds)11:52
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)11:59
*** tleb <tleb!6dbdd9ebc9@2a03:6000:1812:100::10cf> has joined #yocto11:59
*** alessioigor <alessioigor!~alessioig@> has joined #yocto11:59
*** jonesv <jonesv!e7e4272e85@2a03:6000:1812:100::10b5> has joined #yocto11:59
*** raghavgururajan <raghavgururajan!ea769b8000@user/raghavgururajan> has joined #yocto11:59
*** alperak <alperak!~alperak@> has quit IRC (Quit: Client closed)12:03
*** thomas_34 <thomas_34!> has quit IRC (Quit: Client closed)12:04
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 260 seconds)12:06
*** zpfvo <zpfvo!> has joined #yocto12:07
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 256 seconds)12:11
*** zpfvo <zpfvo!> has joined #yocto12:12
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)12:14
*** alessioigor <alessioigor!~alessioig@> has joined #yocto12:14
*** xmn <xmn!> has joined #yocto12:19
*** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has quit IRC (Ping timeout: 260 seconds)12:19
*** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has joined #yocto12:21
*** Starfoxxes <Starfoxxes!> has quit IRC (Ping timeout: 255 seconds)12:22
*** Starfoxxes <Starfoxxes!> has joined #yocto12:34
*** kpo <kpo!> has joined #yocto12:37
*** Guest15 <Guest15!~Guest15@2401:4900:1f28:8fff::48:71f3> has joined #yocto12:45
Guest15Hi, I want to build riscv64 image which will boot from emmc. what changed should I make?12:49
*** lexano <lexano!~lexano@> has joined #yocto12:53
rburtonGuest15: you normally use a specific MACHINE ie one of
rburtonand if that board uses emmc boot then it will build the right files12:53
Guest15any changes to make in local.conf?12:55
rburtonset MACHINE to the right board, look at the configuration to see if it builds the files you want out of the box12:55
Guest15I have seen an option like UBOOT_CONFIG=emmc12:56
JaMameta-qt6 doesn't parse anymore after packagegroup started to use inherit_defer for allarch :/12:58
rburton<insert grumble about how people maintain layers and still don't read any of the development updates or join the community calls>12:59
JaMathis might be difficult to resolve in backwards compatible way (so that newer meta-qt6 could be used with older OE which doesn't have inherit_defer yet12:59
kanavin"To contribute to this layer submit the patches for review using12:59
kanavin[Qt Gerrit]("12:59
kanavinI can imagine, there's some awful CLA to sign too.12:59
kanavinqt company has to make money but...12:59
JaMaLAYERSERIES_COMPAT_qt6-layer = "kirkstone langdale mickledore nanbield" in the bigger issue in this case13:00
JaMathey cannot easily defer inherit nativesdk without using inherit_defer13:00
*** alperak <alperak!~alperak@> has joined #yocto13:01
kanavinthey have a matrix of supported qt versions vs supported yocto versions
JaMaI don't really care about meta-qt6 so I can jsut BBMASK it13:01
kanavinbranching is based on qt versions, not yocto :-/13:02
kanavinwhich is backwards and a mistake, but whatevs13:02
JaMafor meta-qt5 I was branding based on yocto versions, but then people were using different branches for meta-qt5 and other layers, because they required specific version of Qt13:03
JaMaso there are still products shipped with meta-qt5/warrior13:03
*** alperak <alperak!~alperak@> has quit IRC (Client Quit)13:05
*** alperak <alperak!~alperak@> has joined #yocto13:07
*** sakman <sakman!~Thunderbi@> has joined #yocto13:13
*** mvlad <mvlad!~mvlad@2a02:2f08:e805:bb00:1431:4bad:b968:7763> has joined #yocto13:17
*** alperak <alperak!~alperak@> has quit IRC (Quit: Client closed)13:32
*** rcw <rcw!~rcwoolley@> has joined #yocto13:33
*** goliath <goliath!~goliath@user/goliath> has joined #yocto13:33
*** Guest15 <Guest15!~Guest15@2401:4900:1f28:8fff::48:71f3> has quit IRC (Quit: Client closed)13:34
*** Saur_Home22 <Saur_Home22!> has quit IRC (Quit: Client closed)13:41
*** Saur_Home22 <Saur_Home22!> has joined #yocto13:42
*** alperak <alperak!~alperak@> has joined #yocto13:46
*** thomas_34 <thomas_34!> has joined #yocto14:06
thomas_34Hello, is somewhere documention about lockfiles? I would like to lock specific recipes/tasks against. I did something like this, but apparently there is no "lockfile" created when I build the recipe/execute the task: do_compile[lockfile] = "${TMPDIR}/work-shared/cmakedependencies/lockfile"14:07
thomas_34Basically, I want to avoid that certain recipes gets build in parallel by bitbake14:08
RPthomas_34: it is lockfiles, not lockfile14:10
thomas_34thanks RP, ill try that!14:13
*** tlwoerner <tlwoerner!> has joined #yocto14:15
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)14:18
*** prabhakarlad <prabhakarlad!~prabhakar@> has quit IRC (Ping timeout: 250 seconds)14:20
*** prabhakar <prabhakar!~prabhakar@> has quit IRC (Ping timeout: 260 seconds)14:20
thomas_34RP, yep thats it. It is some hidden feature? The documentation is a little bit thin on that topic14:25
RPthomas_34: probably just badly documented, it isn't hidden. I just grep'd to see what other recipes did14:36
RPthomas_34: does say lockfiles14:36
thomas_34RP, weird.. ok: I always search here:
thomas_34And there is just single reference with "lockfile": do_package[sstate-lockfile] = "${PACKAGELOCK}"14:42
thomas_34I was not aware that there is more specific bitbake documentation.14:43
*** florian__ <florian__!> has quit IRC (Ping timeout: 255 seconds)14:46
*** Xagen <Xagen!> has joined #yocto14:47
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto14:51
*** vladest <vladest!~Thunderbi@> has quit IRC (Ping timeout: 268 seconds)14:55
*** thomas_34 <thomas_34!> has quit IRC (Ping timeout: 250 seconds)15:09
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 264 seconds)15:11
*** zpfvo <zpfvo!> has joined #yocto15:12
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)15:16
*** slide333333 <slide333333!> has joined #yocto15:35
rburtonSharing because I missed it:
*** linfax <linfax!> has quit IRC (Ping timeout: 256 seconds)15:38
JaMaFWIW there is also (which I haven't used)15:39
Xogiumso... That'll probably sound annoying or confused to some of y'all... I am definitely confused. I grabbed the hardware layer from st, that is meta-st-stm32mp. At least, from my limited knowledge yet, it seems to be the hardware layer. Then I accept the eula by setting the correct argument in my local.conf file15:41
rburtonJaMa: does that have any yocto-smarts or is it all for making apps?15:42
Xogiumthen trying to build core-image-minimal, when it gets to building mesa, it tells me that I need at least one galium driver. Except, I mean, mesa shouldn't be built, because acceping the eula means one's got access to the gcnano binaries to use the vivante gpu15:42
rburtonXogium: you should harass ST about that15:42
JaMarburton: from the description it looks like it has some, but I haven't tried it15:43
rburtonit also shouldn't be building mesa for core-image-minimal15:43
XogiumI'm not sure what I did then. I'm very confused. I just set the machine to stm32mp15-disco to build for the dev kit. Could that have influenced the list of softwares being built ?15:43
Xogiumso somewhere in that hardware layer they say, yeah when you do that, build mesa15:44
rburtonso my rule of thumb is unless its proven otherwise, assume a vendor BSP is trash15:44
mckoanXogium: if you follow instructions it have to work. Which ecosystem ?15:44
XogiumI tried reaching out to st through the st community thing, like a sort of forum where one can ask questions and get help... Unfortunately I do have to say that with my screen reader, it's quite unusable15:45
Xogiummckoan: the huh 4.1, I think ? Kirkstone15:46
mckoanXogium: it is expected to work out of the box15:46
Xogiumbut I just tried to add that layer onto poky, i.e: I didn't use the full repo thing with openstlinux. Just the hardware layer15:46
Xogiumrburton: as for bsp being trash, I tend to agree with you ;) my previous experience with buildroot shows that this was true. Every buildroot fork was bad, so I stuck with the upstream one so to speak. But I don't think this is possible with yocto ? Or if it is, I have not found how15:49
Xogiumsince each vendor is expected to do their own thing and there's no 'better made' upstream version done all properly15:50
rburtonXogium: my usual experience is that vendors blend "hardware enabling" and "example product" together so its really difficult to build up from a minimal base15:52
Xogiummckoan: yep really not sure what I did wrong or what broke here, because... I mean, I added the layers meta-python and meta-st-stm32mp with bitbake-layer, modified my local.conf file to set the machine, then accepted the eula for it as well. And just like that, it started attempting to build mesa when trying to get core-image-minimal to build, failing with galium driver issue15:52
Xogiumrburton: darn that sucks. I see. Shame, really, because the whole point of layers is to keep hardware and software things separate15:53
mckoanXogium: I'd suggest to start following verbatim the ST documentation, then add customization. In this way you can avoid to complan the vendor15:53
rburtonthis is why the layer compatibility check has explicit checks for "distro" and "bsp" layers15:53
rburtonbut still, vendors do what is easier for them15:54
Xogiummckoan: so using the whole oepnstlinux thing instead of poky ?15:54
Xogiumrburton: well, you have my word ;) if I ever make hardware of my own, I'll keep those two things totally separate15:55
rburtonXogium: :)15:55
mckoanXogium: St adopt a weird development model called 'Ecosystem'. If you break it is up to you to solve issues. Please don't use Poky as first try15:55
Xogiumsometimes doing the easy thing isn't the right choice15:55
mckoanXogium: and they renamed Yocto/OE to OpenSTlinux, LOL15:56
Xogiummckoan: I see. Okay. That's where I got on the wrong foot then, so to speak. I tried to use poky because the yocto project tells you to use this reference distro, and I was like, m'kay so in theory I should be able to use the hardware with poky too15:56
mckoanXogium: always follow the vendor instructions15:57
JaMaso you get the complete set of vendor crap, not just parts of it :)15:57
mckoanJaMa: LOL15:58
XogiumJaMa: yeah :/ but at least it works instead of just producing weird unexpected results15:58
Xogiumthe support for stm32mp in buildroot was subcontracted to bootlin, no wonder it was good quality :p15:59
JaMait might "work", but you might also end with unsupported warrior release or something like that15:59
Xogiumyeah... At least st's got kirkstone, which I plan to use because their latest one was on mickledore which is now dead16:00
mckoanXogium: Mickledore is EOL for YP, but is the latest Ecosystem for ST16:02
* mckoan spent years shoveling cr*p from ST metalayers since Ecosystem 216:03
Xogiummckoan: so they maintain it still, or ? Sorry, hard to wrap my head around this just yet16:03
*** vladest <vladest!> has joined #yocto16:04
Xogiumsounds very unpleasant16:04
mckoanXogium: like many others vendors, they provide their latest version. In this case is based on Micledore. NXP do the same. However we prefer to stay on LTS (Kirkstone) whenever is possible16:04
*** pbiel <pbiel!> has joined #yocto16:04
XogiumI'm glad that at least they are not as bad as other vendors when it comes to upstreaming their SoCs into projects like u-boot and such. One less thing to get annoyed about16:04
Xogiumbut yeah they don't sound really cool for yocto x)16:05
mckoanXogium: depends. It's a free world16:05
Xogiumthanks y'all for getting me on the right track. I really thought I could just use poky with this layer16:08
Xogiumwell I reckon kirkstone it is, because one of the softwares I want to use only has lts branches16:10
mckoanXogium: happy hacking16:11
Xogiummckoan: thanks so much, and rburton too :D16:11
Xogiummckoan: ooh, shiny ! Thank you16:13
mckoanXogium: this is for the new STM32MP1316:14
Xogiumyeah, but can be adapted for mp15 I assume as well ;)16:15
XogiumI also happen to have both mp13 and mp15 so yeepi16:15
*** likewise <likewise!~likewise@2a04:ee41:6:4045:da8e:f295:b893:1986> has joined #yocto16:21
*** likewise <likewise!~likewise@2a04:ee41:6:4045:da8e:f295:b893:1986> has quit IRC (Client Quit)16:21
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)16:26
*** pabigot <pabigot!> has quit IRC (Remote host closed the connection)16:33
*** pabigot <pabigot!> has joined #yocto16:34
*** jmd <jmd!> has joined #yocto16:42
*** florian__ <florian__!> has joined #yocto16:44
*** kpo <kpo!> has quit IRC (Ping timeout: 260 seconds)16:58
*** alperak <alperak!~alperak@> has quit IRC (Quit: Client closed)16:59
*** Saur_Home22 <Saur_Home22!> has quit IRC (Quit: Client closed)17:05
*** Saur_Home22 <Saur_Home22!> has joined #yocto17:05
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)17:05
*** mckoan is now known as mckoan|away17:08
*** Saur_Home22 <Saur_Home22!> has quit IRC (Quit: Client closed)17:23
*** Saur_Home22 <Saur_Home22!> has joined #yocto17:24
*** paulg <paulg!> has quit IRC (Remote host closed the connection)17:30
*** alperak <alperak!~alperak@> has joined #yocto17:30
*** paulg <paulg!> has joined #yocto17:33
*** amitk <amitk!~amit@> has joined #yocto17:37
*** sakman <sakman!~Thunderbi@> has quit IRC (Ping timeout: 256 seconds)17:38
*** florian <florian!> has quit IRC (Quit: Ex-Chat)17:39
*** paulg <paulg!> has quit IRC (Ping timeout: 260 seconds)17:40
*** paulg <paulg!> has joined #yocto17:40
*** florian__ <florian__!> has quit IRC (Ping timeout: 268 seconds)17:43
*** zpfvo <zpfvo!> has quit IRC (Remote host closed the connection)17:43
*** mason <mason!~mason@fsf/member/ChibaPet> has joined #yocto17:56
masonQuestion: What the expected /proc/sys/kernel/pid_max nowadays? I was expecting 32768 but I see 4194304 and I wonder if that's something a co-worker has done, or if it's expected.17:57
Xogiumlways been like that. I just didn't realize, didn't know what it was, and thought that surely everyone must feel uncomfortable as hell in their body. Part of being alive, y'know ? I never asked, because how the hell do you explain that18:01
Xogiumwrong chan18:01
Xogiumbut yep ;p18:01
Xogiumstill stand18:01
masonTurns out, systemd is doing it: /usr/lib/sysctl.d/50-pid-max.conf18:03
Xogiummason: yeah they've done that a while ago, to avoid running out of processes on a system where there could be a lot of activity I think18:04
*** Saur_Home22 <Saur_Home22!> has quit IRC (Quit: Client closed)18:05
XogiumI don't remember when18:05
*** Saur_Home22 <Saur_Home22!> has joined #yocto18:05
Xogiumsomething like 3 years ago ?18:05
masonJust caught me by surprise today.18:05
khemabelloni: please drop from your master-next, I have withdrawn this patch18:07
*** alperak <alperak!~alperak@> has quit IRC (Quit: Client closed)18:08
*** sakman <sakman!~Thunderbi@> has joined #yocto18:08
vvnkanavin: about TEMPLATECONF again, is only the path enforced, i.e. some-dir/conf/templates/foo, or should some-dir be a proper layer as well (i.e. having a conf/layer.conf and listed in BBLAYERS after)?18:11
*** amitk <amitk!~amit@> has quit IRC (Quit: Lost terminal)18:20
khemsource template can be anywhere,  it will copy stuff into builddir/conf though18:27
vvnkhem: I know, but the path is enforced now, hence my question18:29
khemso what is the question :)18:29
vvnkhem: I know you're trying to help, but the question is right above...18:31
vvn"is only the path enforced or should some-dir be a proper layer as well?"18:31
khemso it can be anywhere perhaps covers that ?18:32
khembut usually its better to have them in the project checkout18:32
vvnkhem: kavavin told me yesterday that the path was recently enforced in order to implement discoverability of templates in the future, so my question is does the path containing the template need to be a registered layer or no. So no "anywhere" doesn't cover that18:34
khemhmm that might be, since I have not paid attention18:36
kanavinvvn, template being in a layer is not enforced, and you can place it somewhere else than meta-somelayer/conf/, but it would really not be in the spirit of things. We added that check specifically so that templates would be in standard locations inside layers, and not all over the place.18:47
*** yudjinn_ <yudjinn_!> has quit IRC (Ping timeout: 256 seconds)18:48
kanavinthe idea is to standardize build configuration management in yocto, at least for most use cases18:49
vvnkanavin: ok so I understand that templates in actual layers are recommended18:49
kanavinyes. you can make a layer that's otherwise completely empty.18:50
kanavinmeta-vvn :)18:50
vvnkanavin: it's a bit chicken and egg problem since you need to specify a templateconf path before OE is initial, but I get the standardization part18:50
* vvn hopes meta-core could be split out of openembedded-core so that the oe-init-build-env and friend become just one implementation of an OE-based setup18:51
vvnkanavin: that's what I was doing, I guess a better question would've been: should meta-vvn have a conf/layer.conf18:52
*** dmoseley <dmoseley!> has quit IRC (Quit: ZNC 1.8.2 -
*** dmoseley <dmoseley!> has joined #yocto18:53
kanavinvvn, yes it should be a proper layer, included in your bblayers.conf, because you can then use standard layer setup tooling (bitbake-layers create-layers-setup) to both save the layer configuration and later use it to restore layers from git. This would ensure build templates are a part of it.18:54
kanavinyou can also save templates to it from the active build with bitbake-layers save-build-conf18:54
*** florian__ <florian__!> has joined #yocto18:55
vvngot it, it makes sense for the saving/restoring part18:55
vvnbtw I don't see OE calling setup-layers if it exists18:55
vvndo we want oe-init-build-env and friends to call setup-layers if such script exists in the template directory?18:56
smurraykhem: btw, wasn't too bad to get rust-hello-world building with my WIP updated Rust mixin layer, it now needs to have a Cargo.lock due to the switch to using --frozen with cargo18:56
kanavinvvn, the sequence is 1. run setup-layers to check out the set of layers from git. 2. run oe-init-build-env to set up the build with one of the templates in those layers18:57
kanavinfor making step 2 better I'm developing a higher level thing called oe-setup-build18:57
kanavinthere was a talk about all this in last ELC conference in Prague in the summer18:58
vvnkanavin: I'm greatly interested18:58
kanavinslides and two demo videos18:59
vvnI'd prefer to stick with an upstream standard way to setup a build environment rather than using a third party tool19:00
vvnkanavin: thanks, will check that19:00
kanavinyes, I don't mind if people use kas, repo or submodules, my impression is that yocto world is split evenly between these three. But none of them are suitable for inclusion in yocto proper, and we need something 'out of the box'.19:01
kanavinhence, these new tools. I always get asked 'why not kas?' (or submodules, or repo, depending on who is asking)19:01
vvnI don't want to start a troll, but the answer is quite obvious19:02
vvnany tool that abstract the underlying tool instead of promoting learning of the said tool is badly designed19:02
vvnor at least not suitable for upstream integration19:02
kanavinvvn, one new thing that isn't covered is oe-replicate-build. It's like esdk, but without esdk part - it bundles layer config, build config, and sstate into a self-contained archive.19:03
vvnalso I'm really not a fan of tools generating configuration files (except auto.conf) instead of providing a clean way to integrate static ones maintained by developers19:04
vvnkanavin: so far how do you handle layer fetching and patching yourself?19:05
kanavinvvn, neither am I. I wanted from the start to use static configuration from templates only.19:05
kanavinvvn, not sure I understand the question?19:06
vvnkanavin: do you use submodules, setup-layers, custom scripts?19:06
kanavinvvn, for upstream yocto development I just have a bunch of separate layer repo checkouts that I regularly sync with master branches19:07
kanavinvvn, for customer work, there's a policy at linutronix19:07
kanavinwhich is, use kas if customer's yocto is too old, otherwise setup-layers19:07
vvnkanavin: my issue with setup-layers is that it didn't handle the split bitbake / openembedded-core and I'm really not a fan of the poky repo19:08
vvn(because it isn't developer friendly and makes it a PITA to upstream patches)19:09
kanavinvvn, I don't know, I do all development, both upstream and customer against poky :)19:09
kanavinbasically set up git config to send patches to openembedded-core@ list by default19:10
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 256 seconds)19:10
kanavinoccasionally I have patches for bitbake or poky proper, then I override the to: address by extra parameter to 'git send-email'19:10
kanavinit works19:10
kanavinall from the same poky checkout19:10
vvnunrelated question, is it a bad practice to have a container layer be a layer itself (i.e. meta-foo/ containing a conf/layer.conf file as well as sub layers meta-bar, etc.)19:10
kanavinvvn, I would rather have a container repository with several layers in it at the top level19:11
kanavinbut that repo itself wouldnt be a layer19:11
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto19:11
vvnkanavin: beside making it slightly simpler for new users, I don't really see the value of poky rather than having bitbake, oe-core and meta-yocto checked out.19:11
vvnkanavin: got it thanks19:12
kanavinvvn, poky ensures bitbake and oe-core are checked out to the versions that were tested together. Otherwise people would run into combinations of old bitbake and new core or vice versa all the time, and that can result in very bizarre errors.19:13
kanavinyes, you can check them out separately if you know what you're doing, but we'd rather not make that the default.19:13
*** Saur_Home22 <Saur_Home22!> has quit IRC (Quit: Client closed)19:14
*** Saur_Home22 <Saur_Home22!> has joined #yocto19:14
vvnI always setup my layout based on
kanavinthat's fine. we can teach setup-layers about such bitbake+core setups as well, it's just that I don't use them, and would rather see others add enhancements, now that the basic use case is covered.19:18
vvnkanavin: I'm trying to setup ephemeral build directories and their layers with worktrees. It requires a bit of configuration on the repo (adding layers as remotes) but it's quite handy and developer friendly to add layers for example with: git worktree add build/meta-foo meta-foo/master19:20
kanavinvvn, right, I'm not familiar with 'git worktree' yet19:21
kanavingit is one of those things where there's enough options to fill a lifetime19:21
vvnkanavin: it's the git built-in tool to have checkouts or different branches on your filesystem at the same time (all pointing to the same git repo)19:21
vvnkanavin: if I come up with something useable, I'll share it with you, as it can be a nice writer implementation for makesetup19:23
vvnor an option for oe-setup-layers, idk19:24
*** pbiel <pbiel!> has quit IRC (Quit: Leaving)19:29
kanavinvvn, it needs to have both parts: layer setup creation and restoring layers from that setup19:34
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)19:34
*** alessioigor <alessioigor!~alessioig@> has joined #yocto19:35
vvntrue, I'd like to see a standard way to implement "build layers" for customer projects19:38
*** MrFrank <MrFrank!> has joined #yocto19:50
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)20:28
*** Dracos-Carazza_ is now known as Dracos-Carazza20:30
*** vladest <vladest!> has quit IRC (Remote host closed the connection)20:48
*** sakman1 <sakman1!~Thunderbi@> has joined #yocto21:18
*** sakman <sakman!~Thunderbi@> has quit IRC (Ping timeout: 268 seconds)21:21
*** sakman1 is now known as sakman21:21
Ch^Wkanavin: Is oe-setup-build close to the build wrapper I was describing in my talk at OSSNA?21:27
*** vladest <vladest!> has joined #yocto21:28
*** sakman <sakman!~Thunderbi@> has quit IRC (Ping timeout: 268 seconds)21:28
*** jmd <jmd!> has quit IRC (Remote host closed the connection)21:31
*** kanavin_ <kanavin_!~Alexander@> has joined #yocto21:38
*** kanavin <kanavin!~Alexander@2a02:2454:299:c100:b25:37c3:ea9f:574c> has quit IRC (Ping timeout: 256 seconds)21:40
*** kpo <kpo!> has joined #yocto21:48
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC (Remote host closed the connection)21:55
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has joined #yocto21:55
*** goliath <goliath!~goliath@user/goliath> has joined #yocto21:57
*** mvlad <mvlad!~mvlad@2a02:2f08:e805:bb00:1431:4bad:b968:7763> has quit IRC (Remote host closed the connection)22:58
dvergatalRP: ok with master I don't have such huge issues like previously but yeah, there is only one in regards of GROUPMEMS_PARAM:${PN} that I'm adding user from package which is in USERADD_DEPENDS23:06
*** geoffhp <geoffhp!> has joined #yocto23:18
*** Kubu_work <Kubu_work!> has quit IRC (Quit: Leaving.)23:30
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 268 seconds)23:48
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto23:49
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto23:57

Generated by 2.17.2 by Marius Gedminas - find it at!