| *** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@94.31.104.192> has joined #yocto | 00:01 | |
| *** marka <marka!~marka@135-23-92-18.cpe.pppoe.ca> has joined #yocto | 00:01 | |
| *** OnkelUll_ <OnkelUll_!~user@dude03.red.stw.pengutronix.de> has joined #yocto | 00:02 | |
| *** smooge- <smooge-!smooge@centos/qa/smooge> has joined #yocto | 00:02 | |
| *** kpo_ <kpo_!~kpo@87-206-161-246.dynamic.chello.pl> has joined #yocto | 00:03 | |
| *** svuorela_ <svuorela_!~svuorela@ssh.killmulehill.net> has joined #yocto | 00:05 | |
| *** asrieldreemurr <asrieldreemurr!~asriel@user/asriel> has joined #yocto | 00:05 | |
| *** yudjinn_ <yudjinn_!~yudjinn@c-73-95-114-88.hsd1.co.comcast.net> has joined #yocto | 00:09 | |
| *** kpo <kpo!~kpo@87-206-161-246.dynamic.chello.pl> has quit IRC (*.net *.split) | 00:09 | |
| *** khazakar <khazakar!uid144674@id-144674.ilkley.irccloud.com> has quit IRC (*.net *.split) | 00:09 | |
| *** geoffhp <geoffhp!~geoff@107-185-048-203.res.spectrum.com> has quit IRC (*.net *.split) | 00:09 | |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (*.net *.split) | 00:09 | |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has quit IRC (*.net *.split) | 00:09 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.104.192> has quit IRC (*.net *.split) | 00:09 | |
| *** sotaoverride <sotaoverride!~ctraven@139.68.81.2> has quit IRC (*.net *.split) | 00:09 | |
| *** Saur <Saur!~pkj@nebula.axis.com> has quit IRC (*.net *.split) | 00:09 | |
| *** yudjinn <yudjinn!~yudjinn@c-73-95-114-88.hsd1.co.comcast.net> has quit IRC (*.net *.split) | 00:09 | |
| *** asriel <asriel!~asriel@user/asriel> has quit IRC (*.net *.split) | 00:09 | |
| *** svuorela <svuorela!~svuorela@ssh.killmulehill.net> has quit IRC (*.net *.split) | 00:09 | |
| *** TundraMan <TundraMan!~marka@135-23-92-18.cpe.pppoe.ca> has quit IRC (*.net *.split) | 00:09 | |
| *** dvergatal <dvergatal!~dvergatal@static.50.113.181.135.clients.your-server.de> has quit IRC (*.net *.split) | 00:09 | |
| *** smooge <smooge!smooge@centos/qa/smooge> has quit IRC (*.net *.split) | 00:09 | |
| *** _whitelogger <_whitelogger!~whitelogg@uruz.whitequark.org> has quit IRC (*.net *.split) | 00:09 | |
| *** smooge- is now known as smooge | 00:09 | |
| *** dvergatal <dvergatal!~dvergatal@static.50.113.181.135.clients.your-server.de> has joined #yocto | 00:10 | |
| *** _whitelogger_ <_whitelogger_!~whitelogg@uruz.whitequark.org> has joined #yocto | 00:10 | |
| *** ctraven <ctraven!~ctraven@139.68.81.2> has joined #yocto | 00:10 | |
| *** Saur <Saur!~pkj@nebula.axis.com> has joined #yocto | 00:17 | |
| *** khazakar <khazakar!uid144674@id-144674.ilkley.irccloud.com> has joined #yocto | 00:22 | |
| *** kpo <kpo!~kpo@87-206-161-246.dynamic.chello.pl> has joined #yocto | 00:52 | |
| *** kpo_ <kpo_!~kpo@87-206-161-246.dynamic.chello.pl> has quit IRC (Ping timeout: 264 seconds) | 00:53 | |
| *** marka <marka!~marka@135-23-92-18.cpe.pppoe.ca> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 01:32 | |
| *** marka <marka!~marka@135-23-92-18.cpe.pppoe.ca> has joined #yocto | 01:34 | |
| dvergatal | RP: one additional question because I have found something else https://docs.yoctoproject.org/4.3.2/ref-manual/structure.html#build-tmp | 01:38 |
|---|---|---|
| dvergatal | RP: does it mean that if I will delete the tmp directory I also need to delete sstate-cache? | 01:39 |
| *** lexano <lexano!~lexano@174.119.69.134> has quit IRC (Ping timeout: 276 seconds) | 01:59 | |
| *** davidinux <davidinux!~davidinux@host-95-251-230-145.retail.telecomitalia.it> has quit IRC (Ping timeout: 264 seconds) | 02:04 | |
| *** davidinux <davidinux!~davidinux@host-87-9-16-56.retail.telecomitalia.it> has joined #yocto | 02:05 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 02:16 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 02:19 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 02:19 | |
| *** kpo <kpo!~kpo@87-206-161-246.dynamic.chello.pl> has quit IRC (Remote host closed the connection) | 02:39 | |
| *** xmn <xmn!~xmn@pool-71-105-152-109.nycmny.fios.verizon.net> 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 #yocto | 03: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 #yocto | 03: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 #yocto | 03:21 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Read error: Connection reset by peer) | 03:32 | |
| *** khem <khem!uid220931@id-220931.helmsley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 03:33 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto | 03:34 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Remote host closed the connection) | 03:37 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 03:37 | |
| *** khem <khem!uid220931@id-220931.helmsley.irccloud.com> has joined #yocto | 05:02 | |
| *** camus <camus!~Instantbi@58.246.136.203> has quit IRC (Quit: camus) | 05:21 | |
| *** camus <camus!~Instantbi@58.246.136.203> has joined #yocto | 05:22 | |
| *** OnkelUll_ is now known as OnkelUlla | 05:42 | |
| *** Thorn_ <Thorn_!~Thorn@2001:8a0:dfe1:a200:6415:2cb2:9200:20cb> has joined #yocto | 06: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 #yocto | 06:58 | |
| *** jmd <jmd!~user@2001:a61:2b90:5c01:6de1:a363:1092:21f> has quit IRC (Remote host closed the connection) | 07:13 | |
| *** linfax <linfax!~linfax@eumail.topcon.com> has joined #yocto | 07:19 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 07:29 | |
| *** mckoan|away is now known as mckoan | 07:34 | |
| LetoThe2nd | yo dudX | 07:48 |
| mckoan | LetoThe2nd: hey | 07:54 |
| *** Kubu_work <Kubu_work!~kubu@arennes-654-1-262-155.w2-13.abo.wanadoo.fr> has joined #yocto | 07:55 | |
| Xogium | hiya good people | 07:57 |
| *** zpfvo <zpfvo!~fvo@i59F5CE30.versanet.de> has joined #yocto | 07:57 | |
| *** Tyaku <Tyaku!~Tyaku@bub62-h03-89-84-109-199.dsl.sta.abo.bbox.fr> has joined #yocto | 08:11 | |
| *** thomas_34 <thomas_34!~thomas_34@host-80-81-12-253.static.customer.m-online.net> has joined #yocto | 08:11 | |
| thomas_34 | Good morning guys. Is there somewhere in yocto a tool, or some statistics which record the build-time of a recipe? | 08:12 |
| JaMa | thomas_34: see buildstats.bbclass | 08:16 |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Ping timeout: 264 seconds) | 08:16 | |
| thomas_34 | thanks JaMa :) | 08:16 |
| Tyaku | Hello, 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 eth0 | 08:17 |
| Tyaku | forwarding 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 | |
| Tyaku | In 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 |
| RP | dvergatal: no, sstate-cache can be saved | 08:22 |
| Tyaku | In over terms: I see that only the "all" configuration has effect, interfaces configuration has no effect. | 08:28 |
| Tyaku | Is this normal ? | 08:28 |
| *** vladest <vladest!~Thunderbi@217.192.139.41> has joined #yocto | 08:41 | |
| dvergatal | RP: meaning that I can save sstate-cache and rebuild from it with cleaned tmp? | 08:43 |
| dvergatal | RP: I'm sorry to ask such questions because I'm a little bit confused right now due to this documentation statement | 08:44 |
| dvergatal | RP: and I always thought that I can build with cleaned tmp and sstate-cache than I can remove tmp and rebuild just from sstate | 08:45 |
| dvergatal | RP: correct me if I'm wrong | 08:50 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 08:55 | |
| *** zpfvo <zpfvo!~fvo@i59F5CE30.versanet.de> has quit IRC (Ping timeout: 264 seconds) | 08:55 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:04 | |
| *** zpfvo <zpfvo!~fvo@i59F5CE30.versanet.de> has joined #yocto | 09:09 | |
| RP | dvergatal: that should work, yes | 09:22 |
| RP | Tyaku: that is more of a networking question than I'm able to answer I'm afraid | 09:22 |
| dvergatal | RP: OK so the documentation has a bug than:P | 09:23 |
| dvergatal | RP: 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 today | 09:25 |
| RP | dvergatal: it needs to be clarified, yes as it is unclear. Could you open a bug or send a patch please? | 09:28 |
| dvergatal | RP: OK | 09:33 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.240> has joined #yocto | 09:43 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 09:59 | |
| *** Tyaku <Tyaku!~Tyaku@bub62-h03-89-84-109-199.dsl.sta.abo.bbox.fr> has quit IRC (Quit: Lost terminal) | 10:00 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 10:00 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto | 10:02 | |
| *** alperak <alperak!~alperak@176.33.66.82> has joined #yocto | 10:05 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 10:22 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 250 seconds) | 10:25 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has joined #yocto | 10:28 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.240> has quit IRC (Quit: alessioigor) | 10:33 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.240> has joined #yocto | 10:34 | |
| dvergatal | RP: 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!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 10:42 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 10:42 | |
| *** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:44 | |
| rburton | thomas_34: look up "why is my build so slow" on youtube | 10:49 |
| RP | dvergatal: 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 cases | 10:53 |
| RP | native do_populate_sysroot would be installed for things needed by the rootfs. | 10:53 |
| dvergatal | RP: I'm asking about do_populate_sysroot_setscene | 10:54 |
| *** camus1 <camus1!~Instantbi@58.246.136.203> has joined #yocto | 10:55 | |
| *** camus <camus!~Instantbi@58.246.136.203> has quit IRC (Read error: Connection reset by peer) | 10:57 | |
| *** camus1 is now known as camus | 10:57 | |
| dvergatal | RP: for some reason during this function run fixme does not containe all postinst scripts | 10:57 |
| RP | dvergatal: 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 present | 11:05 |
| RP | dvergatal: 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 code | 11:06 |
| RP | dvergatal: as I said before, we really need reproducible test cases against master which we can then debug and fix. | 11:08 |
| dvergatal | RP: 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 C | 11:12 |
| RP | dvergatal: 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 all | 11:16 |
| RP | I'm drawing a line on that, I'd had enough, sorry | 11:16 |
| dvergatal | RP: sure I will post this use case on this bug | 11:16 |
| dvergatal | where you have stated the commits | 11:17 |
| dvergatal | RP: but first I will switch for a test to newst master to check if it also occur there | 11:21 |
| dvergatal | occurs* | 11:22 |
| *** alperak <alperak!~alperak@176.33.66.82> has quit IRC (Quit: Client closed) | 11:34 | |
| *** alperak <alperak!~alperak@176.33.66.82> has joined #yocto | 11:35 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 11:44 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 11: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@185.178.95.240> has quit IRC (Quit: alessioigor) | 11:59 | |
| *** tleb <tleb!6dbdd9ebc9@2a03:6000:1812:100::10cf> has joined #yocto | 11:59 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.240> has joined #yocto | 11:59 | |
| *** jonesv <jonesv!e7e4272e85@2a03:6000:1812:100::10b5> has joined #yocto | 11:59 | |
| *** raghavgururajan <raghavgururajan!ea769b8000@user/raghavgururajan> has joined #yocto | 11:59 | |
| *** alperak <alperak!~alperak@176.33.66.82> has quit IRC (Quit: Client closed) | 12:03 | |
| *** thomas_34 <thomas_34!~thomas_34@host-80-81-12-253.static.customer.m-online.net> has quit IRC (Quit: Client closed) | 12:04 | |
| *** zpfvo <zpfvo!~fvo@i59F5CE30.versanet.de> has quit IRC (Ping timeout: 260 seconds) | 12:06 | |
| *** zpfvo <zpfvo!~fvo@i59F5CE30.versanet.de> has joined #yocto | 12:07 | |
| *** zpfvo <zpfvo!~fvo@i59F5CE30.versanet.de> has quit IRC (Ping timeout: 256 seconds) | 12:11 | |
| *** zpfvo <zpfvo!~fvo@i59F5CE30.versanet.de> has joined #yocto | 12:12 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.240> has quit IRC (Quit: alessioigor) | 12:14 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.240> has joined #yocto | 12:14 | |
| *** xmn <xmn!~xmn@pool-71-105-152-109.nycmny.fios.verizon.net> has joined #yocto | 12:19 | |
| *** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has quit IRC (Ping timeout: 260 seconds) | 12:19 | |
| *** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has joined #yocto | 12:21 | |
| *** Starfoxxes <Starfoxxes!~Starfoxxe@ip-037-201-004-087.um10.pools.vodafone-ip.de> has quit IRC (Ping timeout: 255 seconds) | 12:22 | |
| *** Starfoxxes <Starfoxxes!~Starfoxxe@ip-037-201-004-087.um10.pools.vodafone-ip.de> has joined #yocto | 12:34 | |
| *** kpo <kpo!~kpo@87-206-161-246.dynamic.chello.pl> has joined #yocto | 12:37 | |
| *** Guest15 <Guest15!~Guest15@2401:4900:1f28:8fff::48:71f3> has joined #yocto | 12:45 | |
| Guest15 | Hi, I want to build riscv64 image which will boot from emmc. what changed should I make? | 12:49 |
| *** lexano <lexano!~lexano@174.119.69.134> has joined #yocto | 12:53 | |
| rburton | Guest15: you normally use a specific MACHINE ie one of https://github.com/riscv/meta-riscv/tree/master/conf/machine | 12:53 |
| rburton | and if that board uses emmc boot then it will build the right files | 12:53 |
| Guest15 | any changes to make in local.conf? | 12:55 |
| rburton | set MACHINE to the right board, look at the configuration to see if it builds the files you want out of the box | 12:55 |
| Guest15 | I have seen an option like UBOOT_CONFIG=emmc | 12:56 |
| JaMa | meta-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 |
| JaMa | this 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 yet | 12:59 |
| kanavin | "To contribute to this layer submit the patches for review using | 12:59 |
| kanavin | [Qt Gerrit](https://codereview.qt-project.org)." | 12:59 |
| kanavin | I can imagine, there's some awful CLA to sign too. | 12:59 |
| kanavin | qt company has to make money but... | 12:59 |
| JaMa | LAYERSERIES_COMPAT_qt6-layer = "kirkstone langdale mickledore nanbield" in https://code.qt.io/cgit/yocto/meta-qt6.git/tree/conf/layer.conf the bigger issue in this case | 13:00 |
| JaMa | they cannot easily defer inherit nativesdk without using inherit_defer | 13:00 |
| *** alperak <alperak!~alperak@176.33.66.82> has joined #yocto | 13:01 | |
| kanavin | they have a matrix of supported qt versions vs supported yocto versions https://code.qt.io/cgit/yocto/meta-qt6.git/tree/README.md | 13:01 |
| JaMa | I don't really care about meta-qt6 so I can jsut BBMASK it | 13:01 |
| kanavin | branching is based on qt versions, not yocto :-/ | 13:02 |
| kanavin | which is backwards and a mistake, but whatevs | 13:02 |
| JaMa | for 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 Qt | 13:03 |
| JaMa | so there are still products shipped with meta-qt5/warrior | 13:03 |
| *** alperak <alperak!~alperak@176.33.66.82> has quit IRC (Client Quit) | 13:05 | |
| *** alperak <alperak!~alperak@176.33.66.82> has joined #yocto | 13:07 | |
| *** sakman <sakman!~Thunderbi@208.111.77.233> has joined #yocto | 13:13 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:e805:bb00:1431:4bad:b968:7763> has joined #yocto | 13:17 | |
| *** alperak <alperak!~alperak@176.33.66.82> has quit IRC (Quit: Client closed) | 13:32 | |
| *** rcw <rcw!~rcwoolley@104.247.247.154> has joined #yocto | 13:33 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 13:33 | |
| *** Guest15 <Guest15!~Guest15@2401:4900:1f28:8fff::48:71f3> has quit IRC (Quit: Client closed) | 13:34 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 13:41 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 13:42 | |
| *** alperak <alperak!~alperak@176.33.66.82> has joined #yocto | 13:46 | |
| *** thomas_34 <thomas_34!~thomas_34@host-80-81-12-253.static.customer.m-online.net> has joined #yocto | 14:06 | |
| thomas_34 | Hello, 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_34 | Basically, I want to avoid that certain recipes gets build in parallel by bitbake | 14:08 |
| RP | thomas_34: it is lockfiles, not lockfile | 14:10 |
| thomas_34 | thanks RP, ill try that! | 14:13 |
| *** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has joined #yocto | 14:15 | |
| *** camus <camus!~Instantbi@58.246.136.203> has quit IRC (Quit: camus) | 14:18 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 250 seconds) | 14:20 | |
| *** prabhakar <prabhakar!~prabhakar@217.163.141.2> has quit IRC (Ping timeout: 260 seconds) | 14:20 | |
| thomas_34 | RP, yep thats it. It is some hidden feature? The documentation is a little bit thin on that topic | 14:25 |
| RP | thomas_34: probably just badly documented, it isn't hidden. I just grep'd to see what other recipes did | 14:36 |
| RP | thomas_34: https://docs.yoctoproject.org/bitbake/dev/singleindex.html#variable-flags does say lockfiles | 14:36 |
| thomas_34 | RP, weird.. ok: I always search here: https://docs.yoctoproject.org/search.html?q=lockfiles&check_keywords=yes&area=default | 14:42 |
| thomas_34 | And there is just single reference with "lockfile": do_package[sstate-lockfile] = "${PACKAGELOCK}" | 14:42 |
| thomas_34 | I was not aware that there is more specific bitbake documentation. | 14:43 |
| *** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 255 seconds) | 14:46 | |
| *** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto | 14:47 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 14:51 | |
| *** vladest <vladest!~Thunderbi@217.192.139.41> has quit IRC (Ping timeout: 268 seconds) | 14:55 | |
| *** thomas_34 <thomas_34!~thomas_34@host-80-81-12-253.static.customer.m-online.net> has quit IRC (Ping timeout: 250 seconds) | 15:09 | |
| *** zpfvo <zpfvo!~fvo@i59F5CE30.versanet.de> has quit IRC (Ping timeout: 264 seconds) | 15:11 | |
| *** zpfvo <zpfvo!~fvo@i59F5CE30.versanet.de> has joined #yocto | 15:12 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 15:16 | |
| *** slide333333 <slide333333!~markus@p200300c1473f1b00c8f9af2ffd8711c1.dip0.t-ipconnect.de> has joined #yocto | 15:35 | |
| rburton | Sharing because I missed it: https://blog.savoirfairelinux.com/en-ca/2024/vscode-yocto/ | 15:38 |
| *** linfax <linfax!~linfax@eumail.topcon.com> has quit IRC (Ping timeout: 256 seconds) | 15:38 | |
| JaMa | FWIW there is also https://www.webosose.org/docs/tools/sdk/vs-code-extension/ (which I haven't used) | 15:39 |
| Xogium | so... 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 file | 15:41 |
| rburton | JaMa: does that have any yocto-smarts or is it all for making apps? | 15:42 |
| Xogium | then 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 gpu | 15:42 |
| rburton | Xogium: you should harass ST about that | 15:42 |
| JaMa | rburton: from the description it looks like it has some, but I haven't tried it | 15:43 |
| rburton | it also shouldn't be building mesa for core-image-minimal | 15:43 |
| Xogium | I'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 |
| Xogium | so somewhere in that hardware layer they say, yeah when you do that, build mesa | 15:44 |
| rburton | so my rule of thumb is unless its proven otherwise, assume a vendor BSP is trash | 15:44 |
| mckoan | Xogium: if you follow instructions it have to work. Which ecosystem ? | 15:44 |
| Xogium | I 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 unusable | 15:45 |
| Xogium | mckoan: the huh 4.1, I think ? Kirkstone | 15:46 |
| mckoan | Xogium: it is expected to work out of the box | 15:46 |
| Xogium | but I just tried to add that layer onto poky, i.e: I didn't use the full repo thing with openstlinux. Just the hardware layer | 15:46 |
| Xogium | rburton: 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 how | 15:49 |
| Xogium | since each vendor is expected to do their own thing and there's no 'better made' upstream version done all properly | 15:50 |
| rburton | Xogium: my usual experience is that vendors blend "hardware enabling" and "example product" together so its really difficult to build up from a minimal base | 15:52 |
| Xogium | mckoan: 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 issue | 15:52 |
| Xogium | rburton: darn that sucks. I see. Shame, really, because the whole point of layers is to keep hardware and software things separate | 15:53 |
| rburton | yes | 15:53 |
| mckoan | Xogium: I'd suggest to start following verbatim the ST documentation, then add customization. In this way you can avoid to complan the vendor | 15:53 |
| rburton | this is why the layer compatibility check has explicit checks for "distro" and "bsp" layers | 15:53 |
| rburton | but still, vendors do what is easier for them | 15:54 |
| Xogium | mckoan: so using the whole oepnstlinux thing instead of poky ? | 15:54 |
| Xogium | *openstlinux | 15:54 |
| Xogium | rburton: well, you have my word ;) if I ever make hardware of my own, I'll keep those two things totally separate | 15:55 |
| rburton | Xogium: :) | 15:55 |
| mckoan | Xogium: 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 try | 15:55 |
| Xogium | sometimes doing the easy thing isn't the right choice | 15:55 |
| mckoan | Xogium: and they renamed Yocto/OE to OpenSTlinux, LOL | 15:56 |
| Xogium | mckoan: 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 too | 15:56 |
| mckoan | Xogium: always follow the vendor instructions | 15:57 |
| JaMa | so you get the complete set of vendor crap, not just parts of it :) | 15:57 |
| Xogium | right | 15:57 |
| mckoan | JaMa: LOL | 15:58 |
| Xogium | JaMa: yeah :/ but at least it works instead of just producing weird unexpected results | 15:58 |
| Xogium | the support for stm32mp in buildroot was subcontracted to bootlin, no wonder it was good quality :p | 15:59 |
| JaMa | it might "work", but you might also end with unsupported warrior release or something like that | 15:59 |
| Xogium | yeah... At least st's got kirkstone, which I plan to use because their latest one was on mickledore which is now dead | 16:00 |
| mckoan | Xogium: Mickledore is EOL for YP, but is the latest Ecosystem for ST | 16:02 |
| * mckoan spent years shoveling cr*p from ST metalayers since Ecosystem 2 | 16:03 | |
| Xogium | mckoan: so they maintain it still, or ? Sorry, hard to wrap my head around this just yet | 16:03 |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has joined #yocto | 16:04 | |
| Xogium | sounds very unpleasant | 16:04 |
| mckoan | Xogium: 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 possible | 16:04 |
| *** pbiel <pbiel!~bielpa@89-70-29-32.dynamic.chello.pl> has joined #yocto | 16:04 | |
| Xogium | I'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 about | 16:04 |
| Xogium | but yeah they don't sound really cool for yocto x) | 16:05 |
| mckoan | Xogium: depends. It's a free world | 16:05 |
| Xogium | ^^ | 16:07 |
| Xogium | thanks y'all for getting me on the right track. I really thought I could just use poky with this layer | 16:08 |
| Xogium | misunderstanding | 16:09 |
| Xogium | well I reckon kirkstone it is, because one of the softwares I want to use only has lts branches | 16:10 |
| mckoan | Xogium: happy hacking | 16:11 |
| Xogium | mckoan: thanks so much, and rburton too :D | 16:11 |
| mckoan | https://koansoftware.com/howto-use-yocto-project-with-the-stm32mp1-embedded-systems/ | 16:13 |
| Xogium | mckoan: ooh, shiny ! Thank you | 16:13 |
| mckoan | Xogium: this is for the new STM32MP13 | 16:14 |
| Xogium | yeah, but can be adapted for mp15 I assume as well ;) | 16:15 |
| Xogium | I also happen to have both mp13 and mp15 so yeepi | 16:15 |
| *** likewise <likewise!~likewise@2a04:ee41:6:4045:da8e:f295:b893:1986> has joined #yocto | 16:21 | |
| *** likewise <likewise!~likewise@2a04:ee41:6:4045:da8e:f295:b893:1986> has quit IRC (Client Quit) | 16:21 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 16:26 | |
| *** pabigot <pabigot!~pab@111.sub-75-236-188.myvzw.com> has quit IRC (Remote host closed the connection) | 16:33 | |
| *** pabigot <pabigot!~pab@111.sub-75-236-188.myvzw.com> has joined #yocto | 16:34 | |
| *** jmd <jmd!~user@aftr-82-135-83-229.dynamic.mnet-online.de> has joined #yocto | 16:42 | |
| *** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 16:44 | |
| *** kpo <kpo!~kpo@87-206-161-246.dynamic.chello.pl> has quit IRC (Ping timeout: 260 seconds) | 16:58 | |
| *** alperak <alperak!~alperak@176.33.66.82> has quit IRC (Quit: Client closed) | 16:59 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 17:05 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 17:05 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 17:05 | |
| *** mckoan is now known as mckoan|away | 17:08 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 17:23 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 17:24 | |
| *** paulg <paulg!~paulg@198-84-237-91.cpe.teksavvy.com> has quit IRC (Remote host closed the connection) | 17:30 | |
| *** alperak <alperak!~alperak@176.33.66.82> has joined #yocto | 17:30 | |
| *** paulg <paulg!~paulg@23-233-30-231.cpe.pppoe.ca> has joined #yocto | 17:33 | |
| *** amitk <amitk!~amit@106.216.175.40> has joined #yocto | 17:37 | |
| *** sakman <sakman!~Thunderbi@208.111.77.233> has quit IRC (Ping timeout: 256 seconds) | 17:38 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 17:39 | |
| *** paulg <paulg!~paulg@23-233-30-231.cpe.pppoe.ca> has quit IRC (Ping timeout: 260 seconds) | 17:40 | |
| *** paulg <paulg!~paulg@198-84-237-91.cpe.teksavvy.com> has joined #yocto | 17:40 | |
| *** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 268 seconds) | 17:43 | |
| *** zpfvo <zpfvo!~fvo@i59F5CE30.versanet.de> has quit IRC (Remote host closed the connection) | 17:43 | |
| *** mason <mason!~mason@fsf/member/ChibaPet> has joined #yocto | 17:56 | |
| mason | Question: 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 |
| Xogium | lways 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 that | 18:01 |
| Xogium | oops | 18:01 |
| Xogium | wrong chan | 18:01 |
| Xogium | but yep ;p | 18:01 |
| Xogium | still stand | 18:01 |
| mason | Turns out, systemd is doing it: /usr/lib/sysctl.d/50-pid-max.conf | 18:03 |
| Xogium | mason: 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 think | 18:04 |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 18:05 | |
| Xogium | I don't remember when | 18:05 |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 18:05 | |
| Xogium | something like 3 years ago ? | 18:05 |
| mason | Just caught me by surprise today. | 18:05 |
| Xogium | ;) | 18:05 |
| khem | abelloni: please drop https://git.yoctoproject.org/poky-contrib/commit/?h=abelloni/master-next&id=05d4095576f86e8793185cadb0c17ac997645178 from your master-next, I have withdrawn this patch | 18:07 |
| *** alperak <alperak!~alperak@176.33.66.82> has quit IRC (Quit: Client closed) | 18:08 | |
| *** sakman <sakman!~Thunderbi@99.209.85.164> has joined #yocto | 18:08 | |
| vvn | kanavin: 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@106.216.175.40> has quit IRC (Quit: Lost terminal) | 18:20 | |
| khem | source template can be anywhere, it will copy stuff into builddir/conf though | 18:27 |
| vvn | khem: I know, but the path is enforced now, hence my question | 18:29 |
| khem | so what is the question :) | 18:29 |
| vvn | khem: 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 |
| khem | so it can be anywhere perhaps covers that ? | 18:32 |
| khem | but usually its better to have them in the project checkout | 18:32 |
| vvn | khem: 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 that | 18:34 |
| khem | hmm that might be, since I have not paid attention | 18:36 |
| kanavin | vvn, 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_!~yudjinn@c-73-95-114-88.hsd1.co.comcast.net> has quit IRC (Ping timeout: 256 seconds) | 18:48 | |
| kanavin | the idea is to standardize build configuration management in yocto, at least for most use cases | 18:49 |
| vvn | kanavin: ok so I understand that templates in actual layers are recommended | 18:49 |
| kanavin | yes. you can make a layer that's otherwise completely empty. | 18:50 |
| kanavin | meta-vvn :) | 18:50 |
| vvn | kanavin: 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 part | 18: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 setup | 18:51 | |
| vvn | kanavin: that's what I was doing, I guess a better question would've been: should meta-vvn have a conf/layer.conf | 18:52 |
| *** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 18:52 | |
| *** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has joined #yocto | 18:53 | |
| kanavin | vvn, 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 |
| kanavin | you can also save templates to it from the active build with bitbake-layers save-build-conf | 18:54 |
| *** florian__ <florian__!~florian@dynamic-002-244-175-240.2.244.pool.telefonica.de> has joined #yocto | 18:55 | |
| vvn | got it, it makes sense for the saving/restoring part | 18:55 |
| vvn | btw I don't see OE calling setup-layers if it exists | 18:55 |
| vvn | do we want oe-init-build-env and friends to call setup-layers if such script exists in the template directory? | 18:56 |
| smurray | khem: 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 cargo | 18:56 |
| kanavin | vvn, 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 layers | 18:57 |
| kanavin | for making step 2 better I'm developing a higher level thing called oe-setup-build | 18:57 |
| kanavin | there was a talk about all this in last ELC conference in Prague in the summer | 18:58 |
| vvn | kanavin: I'm greatly interested | 18:58 |
| kanavin | vvn, https://eoss2023.sched.com/event/1LcOd/setting-up-yocto-layers-and-builds-with-official-tools-2023-edition-alexander-kanavin-linutronix | 18:59 |
| kanavin | slides and two demo videos | 18:59 |
| vvn | I'd prefer to stick with an upstream standard way to setup a build environment rather than using a third party tool | 19:00 |
| vvn | kanavin: thanks, will check that | 19:00 |
| kanavin | yes, 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 |
| kanavin | hence, these new tools. I always get asked 'why not kas?' (or submodules, or repo, depending on who is asking) | 19:01 |
| vvn | I don't want to start a troll, but the answer is quite obvious | 19:02 |
| vvn | any tool that abstract the underlying tool instead of promoting learning of the said tool is badly designed | 19:02 |
| vvn | or at least not suitable for upstream integration | 19:02 |
| kanavin | vvn, 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 |
| vvn | also 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 developers | 19:04 |
| vvn | kanavin: so far how do you handle layer fetching and patching yourself? | 19:05 |
| kanavin | vvn, neither am I. I wanted from the start to use static configuration from templates only. | 19:05 |
| kanavin | vvn, not sure I understand the question? | 19:06 |
| vvn | kanavin: do you use submodules, setup-layers, custom scripts? | 19:06 |
| kanavin | vvn, for upstream yocto development I just have a bunch of separate layer repo checkouts that I regularly sync with master branches | 19:07 |
| kanavin | vvn, for customer work, there's a policy at linutronix | 19:07 |
| kanavin | which is, use kas if customer's yocto is too old, otherwise setup-layers | 19:07 |
| vvn | kanavin: 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 repo | 19:08 |
| vvn | (because it isn't developer friendly and makes it a PITA to upstream patches) | 19:09 |
| kanavin | vvn, I don't know, I do all development, both upstream and customer against poky :) | 19:09 |
| kanavin | basically set up git config to send patches to openembedded-core@ list by default | 19:10 |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 256 seconds) | 19:10 | |
| kanavin | occasionally I have patches for bitbake or poky proper, then I override the to: address by extra parameter to 'git send-email' | 19:10 |
| kanavin | it works | 19:10 |
| kanavin | all from the same poky checkout | 19:10 |
| vvn | unrelated 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 |
| kanavin | vvn, I would rather have a container repository with several layers in it at the top level | 19:11 |
| kanavin | but that repo itself wouldnt be a layer | 19:11 |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 19:11 | |
| vvn | kanavin: 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 |
| vvn | kanavin: got it thanks | 19:12 |
| kanavin | vvn, 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 |
| kanavin | yes, 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!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 19:14 | |
| *** Saur_Home22 <Saur_Home22!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 19:14 | |
| vvn | I always setup my layout based on https://wiki.yoctoproject.org/wiki/Releases | 19:16 |
| kanavin | that'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 |
| vvn | yes | 19:18 |
| vvn | kanavin: 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/master | 19:20 |
| kanavin | vvn, right, I'm not familiar with 'git worktree' yet | 19:21 |
| kanavin | git is one of those things where there's enough options to fill a lifetime | 19:21 |
| vvn | kanavin: 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 |
| vvn | kanavin: if I come up with something useable, I'll share it with you, as it can be a nice writer implementation for makesetup | 19:23 |
| kanavin | sure | 19:24 |
| vvn | or an option for oe-setup-layers, idk | 19:24 |
| *** pbiel <pbiel!~bielpa@89-70-29-32.dynamic.chello.pl> has quit IRC (Quit: Leaving) | 19:29 | |
| kanavin | vvn, it needs to have both parts: layer setup creation and restoring layers from that setup | 19:34 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.240> has quit IRC (Quit: alessioigor) | 19:34 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.240> has joined #yocto | 19:35 | |
| vvn | true, I'd like to see a standard way to implement "build layers" for customer projects | 19:38 |
| *** MrFrank <MrFrank!~MrFrank@mx1.fracta.dev> has joined #yocto | 19:50 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.240> has quit IRC (Quit: alessioigor) | 20:28 | |
| *** Dracos-Carazza_ is now known as Dracos-Carazza | 20:30 | |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has quit IRC (Remote host closed the connection) | 20:48 | |
| *** sakman1 <sakman1!~Thunderbi@99.209.85.163> has joined #yocto | 21:18 | |
| *** sakman <sakman!~Thunderbi@99.209.85.164> has quit IRC (Ping timeout: 268 seconds) | 21:21 | |
| *** sakman1 is now known as sakman | 21:21 | |
| Ch^W | kanavin: Is oe-setup-build close to the build wrapper I was describing in my talk at OSSNA? | 21:27 |
| *** vladest <vladest!~Thunderbi@adsl-89-217-204-83.adslplus.ch> has joined #yocto | 21:28 | |
| *** sakman <sakman!~Thunderbi@99.209.85.163> has quit IRC (Ping timeout: 268 seconds) | 21:28 | |
| *** jmd <jmd!~user@aftr-82-135-83-229.dynamic.mnet-online.de> has quit IRC (Remote host closed the connection) | 21:31 | |
| *** kanavin_ <kanavin_!~Alexander@89.16.135.203> has joined #yocto | 21:38 | |
| *** kanavin <kanavin!~Alexander@2a02:2454:299:c100:b25:37c3:ea9f:574c> has quit IRC (Ping timeout: 256 seconds) | 21:40 | |
| *** kpo <kpo!~kpo@87-206-161-246.dynamic.chello.pl> has joined #yocto | 21:48 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.104.192> has quit IRC (Remote host closed the connection) | 21:55 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.104.192> has joined #yocto | 21:55 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 21:57 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:e805:bb00:1431:4bad:b968:7763> has quit IRC (Remote host closed the connection) | 22:58 | |
| dvergatal | RP: 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_DEPENDS | 23:06 |
| *** geoffhp <geoffhp!~geoff@107-185-048-203.res.spectrum.com> has joined #yocto | 23:18 | |
| *** Kubu_work <Kubu_work!~kubu@arennes-654-1-262-155.w2-13.abo.wanadoo.fr> 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 #yocto | 23:49 | |
| *** kevinrowland <kevinrowland!~kevinrowl@130.41.249.69> has joined #yocto | 23:57 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!