Thursday, 2022-04-07

BhsTalelvvn Yes that is a reasonable idea00:02
*** GLumen_ <GLumen_!~Gregory@97-126-1-223.tukw.qwest.net> has quit IRC (Ping timeout: 260 seconds)00:03
BhsTalelamahnui[m] Can you give me more information about that?00:03
amahnui[m]BhsTalel: It is an internship program that runs twice a year and there is currently a contribution period for those who's application for the program were approved. outreachy.org is their website00:06
vvnsmurray: kergoth: BhsTalel: I get it (maybe). Something along the lines of REQUIRED_DISTRO_FEATURES += "systemd luks btrfs" in the machine configuration, then my distro must enable them and activate the corresponding service packages.00:07
amahnui[m]I thought you were applting for this current cohort00:07
*** Bardon <Bardon!~Bardon@user/Bardon> has quit IRC (Ping timeout: 260 seconds)00:12
*** BhsTalel <BhsTalel!~BhsTalel@102.157.33.91> has quit IRC (Ping timeout: 250 seconds)00:12
*** Bardon <Bardon!~Bardon@user/Bardon> has joined #yocto00:13
*** BhsTalel <BhsTalel!~BhsTalel@196.229.253.52> has joined #yocto00:15
*** davidinux <davidinux!~davidinux@net-188-216-10-245.cust.vodafonedsl.it> has joined #yocto00:20
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has quit IRC (Ping timeout: 248 seconds)00:21
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has joined #yocto00:22
*** BhsTalel <BhsTalel!~BhsTalel@196.229.253.52> has quit IRC (Ping timeout: 250 seconds)00:25
*** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has quit IRC (Remote host closed the connection)00:28
*** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto00:29
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 246 seconds)00:31
*** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has quit IRC (Ping timeout: 256 seconds)00:35
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto00:37
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds)00:42
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto00:47
*** starblue <starblue!~juergen@dslb-094-221-183-068.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 248 seconds)01:10
*** starblue <starblue!~juergen@dslb-094-220-109-125.094.220.pools.vodafone-ip.de> has joined #yocto01:12
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 268 seconds)01:27
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)01:31
*** creich_ <creich_!~creich@p200300f6af0736104488fd6238a6f6f8.dip0.t-ipconnect.de> has joined #yocto01:32
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto01:33
*** creich <creich!~creich@p4ffe0344.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 260 seconds)01:34
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds)01:39
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto01:45
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds)01:50
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto01:53
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto01:55
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 248 seconds)02:03
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto02:09
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds)02:15
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto02:18
*** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)02:20
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds)02:33
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto02:39
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto02:45
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 268 seconds)02:47
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto02:49
*** akiCA <akiCA!~akiCA@user/akica> has joined #yocto02:55
*** amitk <amitk!~amit@103.208.69.67> has joined #yocto02:56
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 268 seconds)02:56
*** codavi <codavi!~akiCA@user/akica> has joined #yocto02:58
*** akiCA <akiCA!~akiCA@user/akica> has quit IRC (Ping timeout: 256 seconds)03:01
*** jclsn0 <jclsn0!~jclsn@149.224.58.250.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto03:02
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 248 seconds)03:04
*** BhsTalel <BhsTalel!~BhsTalel@197.1.4.42> has joined #yocto03:05
*** jclsn0 <jclsn0!~jclsn@149.224.58.250.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 268 seconds)03:09
*** jclsn0 <jclsn0!~jclsn@149.224.58.250.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto03:14
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto04:21
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)04:32
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…)04:55
*** cambrian_invader <cambrian_invader!~cambrian_@50-195-82-171-static.hfc.comcastbusiness.net> has quit IRC (Ping timeout: 272 seconds)05:31
*** cambrian_invader <cambrian_invader!~cambrian_@50-195-82-171-static.hfc.comcastbusiness.net> has joined #yocto05:32
*** BhsTalel <BhsTalel!~BhsTalel@197.1.4.42> has quit IRC (Quit: Client closed)05:38
*** kevinrowland <kevinrowland!~kevinrowl@165.225.243.0> has quit IRC (Quit: Client closed)05:39
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)05:44
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto05:48
*** marcus_ <marcus_!~marcus@82-209-154-112.cust.bredband2.com> has joined #yocto06:00
marcus_Is it possible to build multiple images and include those in the same wic file?06:00
*** rob_w <rob_w!~rob@2001:a61:60c9:601:789d:467b:521d:3399> has joined #yocto06:03
*** mike_87 <mike_87!~sgi@cpe90-146-41-24.liwest.at> has joined #yocto06:16
*** mike_87 <mike_87!~sgi@cpe90-146-41-24.liwest.at> has left #yocto06:17
*** frieder <frieder!~frieder@i59F72C50.versanet.de> has joined #yocto06:30
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto06:42
*** mckoan|away is now known as mckoan06:45
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto06:48
*** mckoan <mckoan!~marco@host-79-3-92-72.business.telecomitalia.it> has quit IRC (Ping timeout: 240 seconds)06:53
*** mckoan <mckoan!~marco@host-79-3-92-72.business.telecomitalia.it> has joined #yocto06:55
mckoanmarcus_: yes, see yocto multiconfig feature or presentations online07:00
*** GillesM <GillesM!~gilles@105.61.128.77.rev.sfr.net> has joined #yocto07:00
marcus_mckoan: thank you07:01
marcus_just to make sure that it is what I'm looking for. I want to create two images, one used as initrd which I want to include into the second image07:05
*** simonew <simonew!~simonew@2a01:c23:bc18:6600:24f9:148f:c02a:f75b> has joined #yocto07:09
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto07:12
LetoThe2ndmarcus_: yes, that is a valid usecase.07:12
LetoThe2ndand yo dudX07:12
LetoThe2ndfor the record: the gdk-pixbuf build error was caused by using ubuntu 22.04 as build host. it might already be fixed there though, the container is a bit dated.07:16
marcus_Can I add a whole image to IMAGE_BOOT_FILES ?07:20
*** camus <camus!~Instantbi@2409:8a1e:911c:7f00:704b:4b0d:8dc4:7c21> has quit IRC (Quit: camus)07:25
*** camus <camus!~Instantbi@2409:8a1e:911c:7f00:1c58:e994:83d7:4365> has joined #yocto07:26
LetoThe2ndmarcus_: don't see are prohibitive reason.07:29
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has joined #yocto07:32
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has joined #yocto07:40
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto07:41
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 246 seconds)07:43
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC (Remote host closed the connection)07:44
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto07:44
*** Schiller <Schiller!~Schiller@dynamic-002-247-253-148.2.247.pool.telefonica.de> has joined #yocto07:45
*** BhsTalel <BhsTalel!~BhsTalel@197.1.4.42> has joined #yocto07:56
*** Schiller41 <Schiller41!~Schiller@dynamic-002-247-253-148.2.247.pool.telefonica.de> has joined #yocto07:57
*** Schiller <Schiller!~Schiller@dynamic-002-247-253-148.2.247.pool.telefonica.de> has quit IRC (Ping timeout: 250 seconds)07:58
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC (Remote host closed the connection)07:59
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto07:59
*** manuel_ <manuel_!~manuel198@62.99.131.178> has joined #yocto08:14
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC (Ping timeout: 246 seconds)08:17
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto08:30
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto08:34
LetoThe2ndwe're seeing almost full rebuilds lately without metadata updates. Anybody else witnessing such?08:37
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Ping timeout: 260 seconds)08:40
JaMaLetoThe2nd: yes, I'm seeing the same, I think global warming is caused by oe-core :)08:45
LetoThe2ndJaMa: also no pointer yet?08:45
RPI was thinking of trying 22.04 too :/08:50
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto08:50
LetoThe2ndRP: it worked well except for gdk-pixpuf. I've rebuild the container and will give it a spin laters. Will let you know.08:50
JaMaLetoThe2nd: I assume you're not using uninative with 22.04, right?08:51
* JaMa is using 22.04 with uninative, but libstdc++ pinned on older version08:51
JaMahaven't seen gdk-pixbuf error yet08:51
LetoThe2ndfor the rebuild thing? no. its my coworkers reporting it "happening roughly once a day", so we're suspecting date leaking in somewhere.08:52
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Ping timeout: 256 seconds)08:54
LetoThe2ndJaMa: one dev reports using crops, and uninative "probably not", e.g. not actively enabled it.08:56
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto08:57
qschulzLetoThe2nd: uninative is enabled by default IIRC08:57
JaMauninative is definitely incompatible with latest 22.04 as mentioned in https://lists.yoctoproject.org/g/yocto/message/5664908:58
LetoThe2ndqschulz: might be, yes.08:58
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Remote host closed the connection)08:59
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto08:59
JaMaand dunfell needs small fix for boost (already queued by Steve), otherwise 22.04 seems usable (in my builds)08:59
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Ping timeout: 256 seconds)09:04
*** dvorkindmitry <dvorkindmitry!~dv@5.167.98.73> has joined #yocto09:09
dvorkindmitrywhy do I have "host contamination" problem? https://pastebin.com/nWWdYY7R09:11
JaMadvorkindmitry: wrong owner of files in package yes, not caused by host contamination (but it does influence if you see the error or not)09:14
JaMadvorkindmitry: see https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d44209:15
JaMadvorkindmitry: and "[yocto] KeyError: 'getpwuid(): uid not found: 1000' in do_package phase" thread for more details09:15
*** GillesMM <GillesMM!~gilles@105.61.128.77.rev.sfr.net> has joined #yocto09:16
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Quit: Leaving)09:18
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 246 seconds)09:36
*** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto09:42
dvorkindmitryJaMa, thank you. but why other libs in other packages are ok for bitbake, althrough they are owned by dv:dv (my localusername)?09:48
dvorkindmitryis it an error to install files using cp -af ... ... in Mkaefile?09:49
*** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto09:51
rburtonyes09:56
rburtonmakefiles should be using 'install' not cp09:56
rburtonspecifically because it doesn't have the ownership behaviour that cp has09:56
*** yolo <yolo!~xxiao@li1120-73.members.linode.com> has quit IRC (Remote host closed the connection)10:00
*** goliath <goliath!~goliath@user/goliath> has joined #yocto10:02
JaMadvorkindmitry: if you have to use cp for whatever reason, then use it with --preserve=mode,timestamps10:11
JaMainstead of -a10:12
dvorkindmitryJaMa, thanks. I really don't want to use cp in my Makefiles :) that was the problem of pjproject Makefile. I made a patch in my recipe10:13
JaMarburton: any idea about https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=f87f81fcc0d11584f4e2ed002d7b9f8c03260db1 ?10:14
*** Schiller41 <Schiller41!~Schiller@dynamic-002-247-253-148.2.247.pool.telefonica.de> has quit IRC (Ping timeout: 250 seconds)10:15
*** starblue <starblue!~juergen@dslb-094-220-109-125.094.220.pools.vodafone-ip.de> has quit IRC (Ping timeout: 268 seconds)10:26
*** BhsTalel <BhsTalel!~BhsTalel@197.1.4.42> has quit IRC (Ping timeout: 250 seconds)10:27
*** starblue <starblue!~juergen@dslb-094-220-109-125.094.220.pools.vodafone-ip.de> has joined #yocto10:28
*** Schiller <Schiller!~Schiller@dynamic-002-247-254-056.2.247.pool.telefonica.de> has joined #yocto10:33
*** Samiha <Samiha!~Samiha@196.203.207.110> has joined #yocto10:49
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto11:02
manuel_Can anyone rephrase this sentence for me? "Because the RRECOMMENDS variable applies to packages being built, you should always attach an override to the variable to specify the particular package whose usability is being extended."11:21
manuel_http://docs.yoctoproject.org/ref-manual/variables.html#term-RRECOMMENDS11:21
manuel_It's explaining why I should use the overlay syntax. This is given as an example: RRECOMMENDS:${PN}-dev += "wireless_package_name"11:22
manuel_In the FILES_${PN}-dev variable, is the "_" also an override? So basically this tells me that RRECOMMENDS works the same as the FILES variable do in terms of override11:26
*** Samiha <Samiha!~Samiha@196.203.207.110> has quit IRC (Quit: Client closed)11:45
JaMayes it works the same and it should be FILES:${PN}-dev11:51
JaMa':' is override separator used since honister (backwards compatible with dunfell, gatesgarth, hardknott as well if you have recent bitbake revision)11:51
JaMaolder releases were using '_' as separator11:52
JaMathere are some cases where _ is part of variable name (not used as override separator), new syntax makes this more clear11:53
*** stanf <stanf!~stanf@pr-svc-em1-014.emea.corpinter.net> has joined #yocto11:56
RPJaMa: is it worth asking the opkg maintainer about that?12:15
JaMaRP: the = operator in RDEPENDS? I was hoping to get confirmation that this works correctly in rpm12:45
JaMaif it's the correct behavior at all12:45
RPJaMa: I think it does work in rpm but I guess we should confirm12:47
JaMait happens only for rootfs task with ptest included which might not be covered by autobuilder12:48
JaMaptest and python3-cryptography12:48
JaMakanavin: do you remember what changed in systemd to require EFI_LD change in https://git.openembedded.org/openembedded-core/commit/?id=e22188e47d2fce2406d9db9c95289b3878eda69f ? the comment above the variable now doesn't make sense12:56
kanavinJaMa, I don't but you can probably undo that change and build to see how it breaks?12:57
RPkanavin: btw, I like the idea of that systemd/connman fix, well spotted!12:58
kanavinRP: I was hoping to fix this quickly, but connman can't quite be easily convinced to ignore eth0 :-/12:58
kanavinI'm on it12:58
RPkanavin: I figured there was some challenge there, thanks!12:59
kanavinRP: this is the fix, and I'm seeing plenty of red in a-full with it :-/ https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/package-version-updates&id=3015be1e71b99fa1c7da283d84b6c58961c31b3313:00
kanavingood thing i didn't send it blindly13:01
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)13:08
manuel_JaMa: Thanks! Was having lunch and came back only now13:16
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto13:17
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto13:20
vvnkergoth: hi -- poking you as you're a feature user ;-) if I get it right, would you add something like IMAGE_CLASSES += "${@bb.utils.contains('COMBINED_FEATURES', 'foo', 'foo-img-class', '', d)}" in your distro, instead of forcing IMAGE_CLASSES += "foo-img-class" in either the machine or distro conf, or polluting the distro with IMAGE_CLASSES:append:foomach = " foo-img-class"?13:34
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Ping timeout: 260 seconds)13:38
vvnsmurray: ^ to conclude yesterday's conversation, I think that's how you "cleanly" split your bsp and distro requirements without too much noise.13:40
RPkanavin: I'll leave that with you then, thanks!13:45
kanavinRP: I figured it out. Apparently some host distro shells write out the above snippet verbatim, e.g. do not convert \n to newlines13:46
kanavinI changed that to installing a proper file from SRC_URI13:46
kanavinsnippet being13:46
kanavinecho "[General]\nNetworkInterfaceBlacklist = eth0\n" > ${D}${sysconfdir}/connman/main.conf13:46
kanavinfedora 35 is one such13:47
RPkanavin: ah, fun. dash vs bash?13:47
kanavinRP: possibly, not sure.13:47
JaMa/bin/echo helps in cases like this13:47
RPkanavin: there is a way to do that more portably with printf iirc but src_uri is easier13:48
LetoThe2ndwhen sharing SSTATE over NFS as described in https://wiki.yoctoproject.org/wiki/Enable_sstate_cache, the usual way to update the shared one is to rsync the locally generated one back after the build is done, right?13:50
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto13:50
JaMaheh even printf isn't reliable in some cases, like with newer make seen today with perf (fixed by https://github.com/torvalds/linux/commit/9564a8cf422d7b58f6e857e3546d346fa970191e)13:51
RPLetoThe2nd: if you have write you can just set SSTATE_DIR to there?13:52
qschulzLetoThe2nd: just set SSTATE_DIR to the nfs mountpoint and people will just populate it?13:52
*** zen_coder <zen_coder!~zen_coder@2a02:8109:a280:2d8d:7481:757c:1037:bf17> has joined #yocto13:53
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto13:53
zen_coderHello, I have created a meta toolchain ("bitbake meta-toolchain") in yocto and would like to add some more components to it, e.g. "xorg" (akaX11) How can I do this?13:54
LetoThe2ndRP: qschulz: I always thought this is not allowed for concurrent builds?13:55
JaMalocks will prevent overwritting the same file concurrently13:55
LetoThe2ndzen_coder: any reason why you went with the meta-toolchain target over an image derived (e)SDK?13:55
RPJaMa: no locks for sstate! Just atomic moves13:56
RPLetoThe2nd: SSTATE_DIR and DL_DIR are special and can be shared13:56
JaMaah sorry, locks for shared DL_DIR, right?13:56
LetoThe2ndRP: ah kay, thanks13:56
RPJaMa: yes13:56
zen_coderLetoThe2nd: I need a toolchain for cross compilation, as slim as possible. And small enought for me to add necessary package as requested13:57
JaMaLetoThe2nd: we were using rsync after build long time ago and switching to shared SSTATE_DIR significantly helped with build times (especially when multiple similar builds were triggered on different builders)13:58
LetoThe2ndzen_coder: is the meta-toolchain target actually *noticeable* smaller? i mean, i kinda doubt it. and the image derived one would exactly match the shipped libraries on the target.14:03
LetoThe2ndzen_coder: and then https://docs.yoctoproject.org/ref-manual/variables.html#term-TOOLCHAIN_HOST_TASK applies14:05
JaMaRP: rburton: rpm was able to install python3-cryptography-ptest, at least I've noticed one not-closed package.manifest in log.do_rootfs while testing it14:14
rfs613when I cherry-pick a fix from master to older branch, do I keep the existing Signed-off-by's ?14:18
JPEWrfs613: Yes14:18
rfs613JPEW: thanks!14:18
*** GLumen_ <GLumen_!~Gregory@97-126-1-223.tukw.qwest.net> has joined #yocto14:19
*** GLumen__ <GLumen__!~Gregory@97-126-1-223.tukw.qwest.net> has joined #yocto14:20
*** GLumen_ <GLumen_!~Gregory@97-126-1-223.tukw.qwest.net> has quit IRC (Ping timeout: 256 seconds)14:24
RPJaMa: There might even have been a bug opened for that in the last week so I'd love a fix :)14:24
RPJaMa: what is really interesting to me is that IMAGE_INSTALL:append = " python3-cryptography python3-cryptography-vectors" works with ipk but IMAGE_INSTALL:append = " python3-cryptography-ptest" does not14:25
JaMathe PV dependency is only on PN-ptest package, right?14:26
RPJaMa: ah, that would explain it then :)14:26
RPJaMa: I was just about to go and look at that14:26
JaManot sure how rpm compares them, but it installed the ptest package even after bumping vectors PR to r114:28
JaMathe package.manifest close() fix already sent, will try to find bug reference for it14:29
JaMahttps://bugzilla.yoctoproject.org/show_bug.cgi?id=1477214:29
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto14:41
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Ping timeout: 248 seconds)14:45
*** xen77 <xen77!~xen@158.110.165.91> has joined #yocto14:49
xen77Hello14:52
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC (Ping timeout: 260 seconds)14:52
*** xen77 <xen77!~xen@158.110.165.91> has quit IRC (Client Quit)14:53
*** xen72 <xen72!~xen@158.110.165.91> has joined #yocto14:54
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto14:57
*** xen72 <xen72!~xen@158.110.165.91> has quit IRC (Quit: Connection closed)14:59
*** Schiller <Schiller!~Schiller@dynamic-002-247-254-056.2.247.pool.telefonica.de> has quit IRC (Ping timeout: 250 seconds)15:00
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto15:00
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Remote host closed the connection)15:02
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto15:03
jclsn[m]How can I have Bitbake pass Artifactory credentials without adding it to the URL?15:03
jclsn[m]I have SOURCE_MIRROR_URL = "https://$ARTIFACTORY_USER:$ARTIFACTORY_TOKEN@artifactory.server:443/artifactory/test_repo/yocto-mirror/" in my local.conf15:04
jclsn[m]Bitbake generates this command wget -t 2 -T 30 --passive-ftp --no-check-certificate --user=$ARTIFACTORY_USER --password=$ARTIFACTORY_TOKEN --auth-no-challenge -P /home/user/Workspace/Yocto/vti1/../downloads 'https://$ARTIFACTORY_USER:$ARTIFACTORY_TOKEN@artifactory.cluster:443/artifactory/user_test_repo/yocto-mirror/libXft-2.3.3.tar.bz2'15:06
jclsn[m]But it only works if I use wget -t 2 -T 30 --passive-ftp --no-check-certificate --user=$ARTIFACTORY_USER --password=$ARTIFACTORY_TOKEN --auth-no-challenge -P /home/user/Workspace/Yocto/vti1/../downloads 'https://artifactory.cluster:443/artifactory/user_test_repo/yocto-mirror/libXft-2.3.3.tar.bz2'15:06
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Remote host closed the connection)15:07
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto15:07
*** xen38 <xen38!~xen@158.110.165.91> has joined #yocto15:08
*** xen38 <xen38!~xen@158.110.165.91> has quit IRC (Client Quit)15:10
*** SpicyChimera <SpicyChimera!~SpicyChim@158.110.165.91> has joined #yocto15:10
SpicyChimeraHello everyone. Can I ask you a few questions regarding Yocto?15:11
vvnSpicyChimera: don't ask to ask15:11
jclsn[m]SpicyChimera: Sure15:11
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Ping timeout: 272 seconds)15:12
SpicyChimeraI'm kinda new to Yocto but the company I'm doing my internship at wants to use it on their board - a Variscite DART-MX8M-PLUS. They are gonna use it for Computer Vision stuff. Do I need to rebuild every time I need to "install" a package? If so, is there a way to save some time?15:13
LetoThe2ndSpicyChimera: everything that can be reused will be reused, so unless you're doing changed deeper in the application stack consecutive rebuilds of the image will be considerably faster.15:14
LetoThe2ndSpicyChimera: the keyword is SSTATE here15:15
rburtonSpicyChimera: you can use package management to just install on the target15:16
rburtonSpicyChimera: https://docs.yoctoproject.org/dev-manual/common-tasks.html#using-runtime-package-management15:16
SpicyChimeraThanks!15:18
*** stanf <stanf!~stanf@pr-svc-em1-014.emea.corpinter.net> has quit IRC (Ping timeout: 250 seconds)15:18
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto15:25
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat)15:26
jclsn[m]Hmm so I could figure out how to generate the right wget command now. Guess I have to work with PREMIRRORS instead of SOURCE_MIRROR_URL15:26
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Remote host closed the connection)15:30
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Ping timeout: 268 seconds)15:30
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto15:30
jclsn[m]No SOURCE_MIRROR_URL should provide the PREMIRRORS, but when I use BB_FETCH_PREMIRRORONLY it doesn't work15:33
*** SpicyChimera <SpicyChimera!~SpicyChim@158.110.165.91> has quit IRC (Quit: Connection closed)15:33
RPJaMa: I tested with the deb backend and that also shows an error so rpm works, ipk and deb do not15:36
jclsn[m]It only tries to fetch from Artifactory when I add BB_NO_NETWORK = "1", but even if I allow it with BB_ALLOWED_NETWORKS, it doesn't work15:39
RPJaMa: Looks like this part of the design of debian :(15:48
RPJaMa: an exact version specification needs to include the PR in our terms (or it is assumed to be 0 whilst ours is r0)15:49
*** GLumen__ <GLumen__!~Gregory@97-126-1-223.tukw.qwest.net> has quit IRC (Remote host closed the connection)15:51
*** GLumen__ <GLumen__!~Gregory@97-126-1-223.tukw.qwest.net> has joined #yocto15:51
dvorkindmitryI need sys/io.h in SDK. what package generates it?15:56
*** GLumen__ is now known as GLumen15:57
rburtondvorkindmitry: that's a x86 specific header, so is your target x86?15:59
dvorkindmitryrburton, no, it is ARM15:59
rburtonthen your SDK won't have sys/io.h15:59
*** kevinrowland <kevinrowland!~kevinrowl@165.225.243.0> has joined #yocto16:00
manuel_I16:01
*** frieder <frieder!~frieder@i59F72C50.versanet.de> has quit IRC (Remote host closed the connection)16:02
kergothvvn: yeah, that seems like a good approach to me. That sort of thing is how best to handle it, avoids hardcoding machine or distro references in one another16:03
vvnkergoth: I understand better now, thank you. If I may ask, how would you configure the distro to enable hardware acceleration for the BSP beaglebone for example? This requires PREFERRED_PROVIDER_virtual/gpudriver = "ti-sgx-ddk-km" and a few other providers that aren't set by default.16:07
kergothI'd make all of that conditional on a feature in MACHINE_FEATURES, then it's up to you if you want that feature to be default for a certain machine or machine variant or if you want the distro to append to MACHINE_FEATURES. it crosses the boundaries, but it's sometimes necessary, and is still better than hardcoding machine or distro references. Personally i'd probably create a machine that includes the non-accelerated machine and16:13
kergoththen enables the machine feature, but your call16:13
*** BhsTalel <BhsTalel!~BhsTalel@197.0.9.173> has joined #yocto16:13
vvnkergoth: I see. But this is confusing as I thought the machine features are supposed to be invariant, describing "what features I have", compared to the distro features describing "what features I want".16:16
kergothIt's true, but it's fuzzy when it's about enabling a function of the machine/bsp. Ideally you'd probably obey combined features instead of machine features in the machine layer, if it's a non-default machine feature, but I'm not sure if that's commonly done or not.16:17
kergothThis stuff should probably be in a guide to BSP/machine layer construction :)16:18
kergothaka "Vendors: here's how to improve your layers to not be a hot mess" :)16:18
vvnthere is a "gpu" machine features for that, but somehow you need to say "I want to use it". There is the "hwcodecs" image features, but the preferred providers must be set at the distro level. I guess we must introduce "hwaccel" distro feature maybe and have the BSP enable their GPUs by default?16:19
vvnSo beaglebone.conf for example sets all providers to ti-sgx-ddk-{k,u}m, then default-distrovars.inc or a core include file like that sets these providers to "mesa" or such generic packages if the feature isn't combined16:22
kergothYeah, you have a few options for how to express that desire to use the feature. Either you use a machine variant that enables it, or obey the distro's preference on it. I think either are reasonable options16:22
kergothafaik16:22
rburtonRP: posted an improvement for the meta-virt autobuilder run.  i propose we enable it for master runs to keep zeddii on his toes ;)16:23
rburtonits deliberately lean so its something that actually works and can be incrementally expanded over time16:23
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection)16:24
vvnkergoth: is it safe to reference DISTRO_FEATURES in the machine configuration, given the source order?16:24
vvnthat seems weird16:26
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto16:26
RPrburton: did you mention this to zeddii?16:27
rburtonwe've spoken16:27
rburtonhe can veto making it run by default, I haven't sent anything to make that happen yet16:28
rburtonon-demand runs are still better than what we have currently16:28
*** u1106 <u1106!~quassel@ec2-18-193-68-189.eu-central-1.compute.amazonaws.com> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)16:29
*** florian <florian!~florian@dynamic-093-133-184-188.93.133.pool.telefonica.de> has joined #yocto16:30
*** manuel_ <manuel_!~manuel198@62.99.131.178> has quit IRC (Ping timeout: 268 seconds)16:31
*** u1106 <u1106!~quassel@ec2-18-193-68-189.eu-central-1.compute.amazonaws.com> has joined #yocto16:32
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Ping timeout: 260 seconds)16:32
RPDoes anyone want to feel really ill? https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/t22216:34
RPJaMa, rburton: "fix" for the python3-crypto issue on deb/ipk16:34
RP^^^16:34
rburtonewww16:34
rburtonthe alternative is to revert the dependency16:35
rburtoni was just trying to be clever16:35
RPrburton: it doesn't change the fact that this is just broken16:35
* RP wishes he had some better idea but this was the best I could come up with16:36
kergothvvn: it can be done as long as no forced immediate expansion is done. I.e. ${@} is evaluated when it's used, not where it's defined, so source order isn't an issue. And yes, it does feel a little odd to go that route. I'd probably have a 'beaglebone-hwaccel' machine variant myself. but it's personal preference. i'd still make it a feature so it's easier to enable and disable, though16:37
RPrburton: -helper change added16:40
RPrburton: when you say "enable for master runs", you mean a-full?16:41
rburtonyes16:41
RPrburton: will be interesting to only do that on master. We'd need to remove the meta-virt entry from the other helper branches16:41
RPrburton: I'm not even trying to make something "only master" in the autobuilder2 code16:42
rburtonhah fair enough16:42
rburtonwell the change i did was low impact and should be easily backported...16:43
rburtonnow to figure out why testimage doesn't work16:43
RPrburton: I guess that is for me to try then? :)16:44
rburtonnot at all16:44
zen_coderLetoThe2nd: where do I put this variable TOOLCHAIN_HOST_TASK? In which file?16:44
BhsTalel Hello, can anyone explain to me (uninative) and (yocto-uninative.inc), I am not getting its definition and use case.16:45
BhsTalelThanks16:45
zen_coderI mean TOOLCHAIN_TARGET_TASK16:45
RPrburton: it doesn't cherry-pick to hardknott FWIW, it does to honister16:45
RPBhsTalel: it allows you to share native sstate between different distros and OSes16:54
BhsTalelRP So if I want native builds run faster I include uninative in my distro ?17:00
zen_coderwhat are the package names in yocto for X11 and OpenGL? I need to add the Qt depedencies to make toolchain17:05
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving)17:05
* rfs613 thinks it's time to switch from using poky to separate repos. It's too hard to watch all the branches (-next, -nut) via poky. Any advice/tips on how to set this up, or otherwise how to arrange for development?17:06
rfs613also any pointers to articles/blog/FAQ about tools to manage the repos (repo/kas/etc) would be appreciated17:08
rburtoni find kas a lot easier than repo for controlled builds17:13
*** florian <florian!~florian@dynamic-093-133-184-188.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds)17:13
rburtonbut for local hacking, i have hand-controlled repos because that's easier17:13
rfs613hmm okay, I have hand-controlled ones now (but using the poky-aggregate), and finding it's tedious to go and make sure they are all aligned.17:14
vvnkergoth: board variants can be tricky with the MACHINEOVERRIDES order, but they are definitely simpler to manage once you figure it out. I'm using a 'bbb' variant too at the moment. I'll try to come up with something simple for the BSP vendors.17:15
BhsTalelFor local work, hand-controlled repos are easier, for automation I think KAS is okay, but I think repo provides more control17:15
rfs613I could script this I suppose but it seems like it is common enough situation that there should be an obvious solution17:15
rburtonif the job is 'update all these repos to this branch' then that's either a few lines of sh, or a little kasfile which you tell it to just fetch and not build anything17:16
vvnrfs613: to make sure your repos are aligned, kas is the best, since it ensures that your repos match the configure refspec plus your patches on top of them.17:16
rburtonyou've not really said what your goal is though, so it's hard to comment17:17
rburtonfor local hacking i have hand controlled branches because its only occasionally that they're actually on upstream branches, normally they're on local feature branches17:17
vvnThe repo patching is huge for me and it's why I stick with kas, even though it has its flaws.17:17
rfs613rburton: true, I have not been very specific, because I am mentally still trying to figure it out ;-)17:18
rfs613but take for example the vim update patch which i posted today and then realized RP already did it.17:18
sotaoverridehow do we tell the am image recipe to make a rootfs read only?17:18
rfs613normally I have been searchign CVEs in the mailing lists to see if they are addressed on dunfell.17:18
sotaoverridetell an*17:18
rburtonsotaoverride: https://docs.yoctoproject.org/search.html?q=read+only+rootfs&check_keywords=yes&area=default17:19
rfs613but this one got fixed in stable/dunfell-nut without any emails it seems, so I didn't see it.17:19
rburtonrfs613: that's staging so just a race condition between you posting it and the author posting it17:19
rfs613rburton: well in this case it landed 2 days ago, but in a branch I didn't really look at.17:20
rburtonsotaoverride: leads to https://docs.yoctoproject.org/dev-manual/common-tasks.html#creating-a-read-only-root-filesystem17:20
Saur[m]rfs613: So far no one has found a common solution to that problem. For what it's worth, we use `repo` and I like it. We also have a Git submodules alternative, but it is horrible to work with IMHO.17:20
rfs613(and that I don't have locally, because I am using poky rather than separate repos)17:20
rfs613I wonder if someone has collected pro/con lists for each of these approaches.17:22
vvnrfs613: there's no perfect too because it depends on your usage. As a build system developer, I like kas because it allows me to applied patches on top of my layers. It's handy to cherry-pick upstream patches or stage the one I want to contribute back. For a software developer it won't really matter.17:25
rburtonrfs613: of course you don't want to do local builds with the staging branches like dunfell-nut as they might be broken: the point is that they're in testing17:28
kergothkas really needs to get the ability to load plugins from layers at some point, that'd open up a lot of flexibility17:28
rburtonkergoth: it used to, paulbarker removed it :)17:29
rburtoni also want to add it back17:29
BhsTalelI like how KAS provides a way to patch layers and it is useful to test patches on layers before committing them to upstream, but I noticed that KAS made lot of developers, some of them are my coworkers) uses patches in production, which make the project cannot be built without KAS.17:29
rburtonkergoth: my imaginary fork of kas has out-of-tree plugin support17:29
kergothheh :)17:29
rburtonBhsTalel: yeah that's bad form.  i only use layer patches for short term workarounds.  if they're hanging around then just have a proper fork of the layer.17:30
vvnyeah but kas as a strong bias on reproducibility, so loading plugins, out-of-tree stuffs etc. isn't gonna happen17:30
kergothI don't think that would prevent reproducibility17:31
kergothhaving the ability to add new commands for your product or distro would be invaluable17:31
vvnI hate the fact that it is too intruisive, overriding the bblayers.conf and local.conf and not working well with other default config files, but that's the reason why17:31
vvnho and I use kas for its container too, I'm never building yocto on my host machine.17:32
BhsTalelFor my projects I always choose between `repo` or `git submodules` for developers, after that one KAS file is used for the pipeline.17:32
vvnGiven the bitbake built-in fetcher, supporting patches and all, it's too bad that we cannot come up with a layer.bbclass or something17:33
vvndescribing source, patches, dependencies to other layers, all that using usual bitbake recipes.17:34
kergothvvn: there used to be an oe fork that provided a 'oe bakery' tool, it was an 'oe' command on the host that could clone a repo that would hold a .conf that defined a variable in standard bitbake format the list of layers as urls, and would do the layer setup17:34
kergothoe-lite was the project17:34
kergothI always rather liked that idea17:35
kergoththen 'oe build', etc called out to the underlying bits that it cloned before17:35
kergothoe clone git://foo && cd foo && oe build foo; or the like17:35
kergothvvn: there's an item in the yocto proejct future dirctions page to address this, providing a definitive mechanism for layer cloning and management17:36
kergothbut it's non-trivial and requires knowledge of both project history and the use cases and alternative projects17:36
kergothbut it's a known gap17:37
kergothhttps://wiki.yoctoproject.org/wiki/Future_Directions#Layer_setup.2Fconfiguration17:37
vvnI totally understand that it's a tricky topic17:37
vvnbut I would still love to see all these OE-Core crappy init env scripts gone :)17:38
kergothI don't think anything is going to meet all needs, we just need something that's good enough for most. those with more specific needs can extend or use something else17:38
kergothI do think the plugin capability is going to be key to allow for such extension17:38
*** mckoan is now known as mckoan|away17:39
rfs613for me it would be great to have at least one officially supported way... because right now the next step is unclear, I have to go research each of these tools to see how they work, if they fit my use case, etc. Repeat for each new potential contributor...17:39
kergothI think kas isn't *too* far off from what we need, just might want to leverage our existing file format if possible, and make it more extensible17:39
*** BhsTalel30 <BhsTalel30!~BhsTalel@197.2.30.112> has joined #yocto17:39
kergothyep, it's a definite barrier and adds to our already steep learnign curve ;)17:40
vvnkergoth: true, similarly to buildroot, you want a stable building base you can base your project on, which reads your layer recipes, fetch them all and build.17:40
vvnkergoth: yeah but forcing the use of local.conf only, forcing the non-bitbake syntax, it just abstracts bitbake too much17:41
kergothI would like a clone command that does the initial clone of the repo that holds the .yaml/.conf to start things off, rather than having to clone that initial layer or project and run kas17:41
vvnit's one of these tools that make users know how to use kas but not bitbake, this is what I hate about it.17:41
*** florian <florian!~florian@dynamic-093-133-184-188.93.133.pool.telefonica.de> has joined #yocto17:41
kergothYeah, that's a good point. Encourages a lack of knowledge of the underlying tools17:42
kergothToo much17:42
BhsTalel30I am developing a generic class for service management (systemd, init.d, busybox), so any recipe can inherit the class and set the service files only and the class handles everything like:17:42
BhsTalel30* recipe:17:42
BhsTalel30SERVICE_FILES[systemd] = "example.service"17:42
BhsTalel30SERVICE_FILES[pkgname.systemd] = "otherexample.service"17:42
kergothAdding ease of use is one thing, but you can't avoid learning the underlying tooling17:42
BhsTalel30SERVICE_FILES[sysvinit] ...17:42
BhsTalel30I already done the systemd part17:42
BhsTalel30What do you think ?17:42
*** BhsTalel <BhsTalel!~BhsTalel@197.0.9.173> has quit IRC (Ping timeout: 250 seconds)17:42
vvnI want a non-intrusive tool which just bootstraps an OE-Core based project, not wraps everything. i.e. expect the user to call bitbake.17:43
kergothI wouldn't mind the ability to add extra commands to wrap underlying commands, but it shouldn't hide the details. I'd actually like it to show the underlying command being run, even17:43
kergothi.e. 'oe build target' prints '> bitbake target' after setting up the environment17:43
kergothjust to avoid the need to source something into your current shell17:44
kergoth(if desired)17:44
kergothbut it should be additional, not required17:44
*** BhsTalel <BhsTalel!~BhsTalel@102.158.48.192> has joined #yocto17:45
kergothi'd like to see proper completions generation and stuff too. `eval $(oe init zsh); bitbake foo`17:45
kergothno reason it couldnt do that at the same time it adjusts PATH and all17:45
vvnkergoth: like everytimes you have a variable issue, one says "run bitbake -e recipe and grep". Ho well ok, let me type ./kas-container shell ./project.yml -c 'bitbake -e recipe'17:47
kergothactually you could make the easiest method of adding new subcommands to the tool just a list of aliases defined in its .conf file. 'SUBCOMMANDS[modify] = "devtool modify"' or the like17:47
*** BhsTalel30 <BhsTalel30!~BhsTalel@197.2.30.112> has quit IRC (Ping timeout: 250 seconds)17:47
kergothugh yes there's a fair bit of necessary boilerplate with kas that'd be nice to avoid17:48
vvnexactly17:48
kergothjust assume the project config path if it's not explicitly set, etc17:48
* rfs613 starts a list of the tools, with pro/cons. Very preliminary at this point... https://docs.google.com/document/d/1lUERORP3PTq7JuygRabVBxUYDYfvAST8bIh5b7gi1Kk17:49
vvnBhsTalel: with your class, how do you configure manager-specific bits like Wants=foo.service Before=bar.service or WantedBy=some.target?17:49
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)17:50
BhsTalelvvn The .service files are provided by the developer, I am just automating the `FILES_${PN} , SYSTEMD_SERVICES, etc` files of the service classes and handling `do_install` also18:01
*** willo <willo!~quassel@60-241-162-73.static.tpgi.com.au> has quit IRC (*.net *.split)18:03
*** willo <willo!~quassel@60-241-162-73.static.tpgi.com.au> has joined #yocto18:05
*** simonew <simonew!~simonew@2a01:c23:bc18:6600:24f9:148f:c02a:f75b> has quit IRC (Quit: Client closed)18:09
*** florian <florian!~florian@dynamic-093-133-184-188.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds)18:26
*** vvn <vvn!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.5)18:31
*** vvn <vvn!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has joined #yocto18:32
*** manuel_ <manuel_!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto18:48
rfs613kergoth: you mentioned "oe" commands a few times, like "oe init zsh"... I don't see this in my yocto. Where does it come from?18:59
*** vvn <vvn!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.5)18:59
kergothIt doesn't exist, we're brainstorming18:59
rfs613ah, very good18:59
kergothwere talkinga bout theoretical alternatives for layer adn repo management and configuration19:00
*** vvn <vvn!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has joined #yocto19:00
rfs613ok, and earlier you said you'd like to start with cloning a repo that only has .yaml/.conf files. I'm a bit puzzled because that is exctly how it seems it should work today, for both repo and kas.19:01
BhsTalelMaybe a simple idea like "Pass a layers conf file to the build source file, and then the sh file fetches them and setups up bblayers.conf and local.conf accordingly"19:02
BhsTalelSo, just the developer needs to clone poky only, and then pass the conf file for it.19:03
dvorkindmitrypulled latest "dunfell" branch and got strange "m4-native" recipe build error: https://pastebin.com/jTcSTQK319:09
*** marc3 <marc3!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has quit IRC (Quit: WeeChat 3.4)19:09
rfs613dvorkindmitry: not much help to you, but I'm on dunfell with same m4-native/1.4.18-r0, no issues building it19:11
dvorkindmitryrfs613, so probably some host incompatibility? hmmm...19:12
rfs613dvorkindmitry: did it build for you previously? do you have all host tools (autoconf in particular) installed?19:14
*** fabian <fabian!~fabian@187.56.88.38> has joined #yocto19:15
rfs613https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html#build-host-packages19:15
rfs613actually there's a better link in the reference manual19:15
*** marc2 <marc2!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has joined #yocto19:17
fabianERROR: Setscene task /home/{user}/yocto/sources/poky/meta/recipes-extended/cronie/cronie_1.5.5.bb:do_populate_sysroot in both covered and notcovered.19:17
fabianHi all, does anybody know how to fix the "both covered and notcovered" issue? I only saw it recently after recompiling with the dunfell-branch.19:18
rfs613fabian: I got that the other day, 600 times, once for each recipe. But it only happened once, and have not seen it again.19:18
fabianOk thanks! I will re-run after this initial run and see if it disappears.19:18
*** Guest94 <Guest94!~Guest94@151.61.118.215> has joined #yocto19:21
*** Guest94 <Guest94!~Guest94@151.61.118.215> has quit IRC (Client Quit)19:25
*** vvn <vvn!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.5)19:28
*** vvn <vvn!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has joined #yocto19:28
*** vvn <vvn!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.5)19:33
*** vvn <vvn!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has joined #yocto19:35
*** florian <florian!~florian@dynamic-093-133-184-188.93.133.pool.telefonica.de> has joined #yocto20:03
*** cambrian_invader <cambrian_invader!~cambrian_@50-195-82-171-static.hfc.comcastbusiness.net> has quit IRC (Ping timeout: 246 seconds)20:05
*** cambrian_invader <cambrian_invader!~cambrian_@50-195-82-171-static.hfc.comcastbusiness.net> has joined #yocto20:09
*** fabian <fabian!~fabian@187.56.88.38> has quit IRC (Quit: Client closed)20:20
smurraykhem: the recent tweak to the wxwidgets package config stuff breaks if one has wayland + opengl in DISTRO_FEATURES (w/o x11):  https://paste.debian.net/1237163/20:25
smurraykhem: it's not clear to me if the fix is to change the no_gui package config conflicts or not...20:25
*** rob_w <rob_w!~rob@2001:a61:60c9:601:789d:467b:521d:3399> has quit IRC (Read error: Connection reset by peer)20:37
*** manuel_ <manuel_!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 248 seconds)20:38
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection)21:06
*** amitk <amitk!~amit@103.208.69.67> has quit IRC (Ping timeout: 268 seconds)21:21
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto21:31
*** florian <florian!~florian@dynamic-093-133-184-188.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds)21:42
* moto-timo immediately starts spamming zeddii at arm dot com22:00
vvnsmurray: lol I came to the channel to mention exactly this... Having the same no_gui issue22:00
moto-timozeddii: your warranty for your car has expired! Urgent! You must buy new coverage!22:01
vvnbtw is this a standard distro feature or yet another arbitrary chosen feature from a package?22:01
moto-timovvn:  you speak as if there is some cosmic council of sages that has everything figured out. We're all just doing the best we can. Patches welcome.22:02
vvnmoto-timo: I mean that additional user features are fine, but machine/distro/image features must be standard and could even end up listed on layers.openembedded.org22:04
vvnmoto-timo: nothing to take personal here :)22:05
moto-timovvn: my skin has grown very thick in the last decade.22:05
vvnI guess it's a good thing22:05
moto-timovvn: but as almost the only person (some folks at WR as well) that is actually trying to maintain layers.openembedded.org I cry foul frequently.22:06
moto-timo"you" (universal you) use these tools for free and don't contribute a thing. Guess what happens?22:06
* moto-timo apologizes for being in a FOSS is in trouble mood22:07
vvnlayers.openembedded.org is very nice, I use it all the time to look recipes location or have a quick web view of the source22:07
vvnmoto-timo: and here you assume that everyone who complains don't contribute back. Nice.22:08
vvnSure that skin is that thick? ;)22:08
moto-timovvn: thick skin still exudes some bodily fluids22:09
*** dvorkindmitry <dvorkindmitry!~dv@5.167.98.73> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)22:10
moto-timoI will leave this alone, but I am specifically concerned (as many of us are) about the maintainership of https://git.yoctoproject.org/layerindex-web/22:11
moto-timoLike many of our core infrastructure tools, we do not have a maintainer. period.22:11
moto-timoAny code left alone for 2+ years will bit rot. This I can assure you.22:12
vvnmoto-timo: hmm sorry if 'arbitrary chosen feature' pissed you off initially, but I don't really see the point you're trying to make here22:15
zeddiimoto-timo. I deserved that troll!!22:15
moto-timovvn: very simple. you use layers.openembedded.org. How is that being kept alive?22:16
moto-timozeddii: yup.. trolling happens and is normal.22:16
* moto-timo is being trolled now.22:16
vvnmoto-timo: ok but why the attack about the layer index?22:16
zeddiiahah buggers. are using my bad email address on that thread. Now I'm getting to enjoy all the bounces.22:17
moto-timovvn: I am not attacking you. I am trying to scream at the universe that please support us in keeping it going. Who contributed last? Look at the repo and then come back.22:17
moto-timozeddii: I am going to start selling you insurance on all your emails.22:18
* moto-timo sighs and thinks about cocktails.22:18
zeddiivvn. I'd suggest that there's no sense talking about any features / additions to the layer index, when it hasn't even been getting maintained properly for what it currently does. which is what moto-timo is yelling at the universe about :)22:19
zeddiiin between trolling me that I can't type my own email address properly :)22:19
* moto-timo pushed commits that haven't been reviewed since January.22:19
* moto-timo considers yoga instead of cocktails22:20
zeddiimoto-timo. do you have push privs ? I'd say "ship it!" :)22:20
moto-timoSHIP IT22:20
moto-timoI also have super secret privs to burn down the instance.22:21
* moto-timo will not ever do that intentionally.22:21
moto-timoAlso, CROPS. do you use it? guess who maintains it?22:22
* moto-timo should _really_ shut up now.22:22
vvnzeddii: ho I see. Well I'm not asking for this, I just mentioned the layer index as an example for listing standard features. Forget about the example if that is a problem.22:22
moto-timoIRC has absolutely no nuance of body language or tone... we only have that because we meet IRL at conferences.22:23
moto-timoI have been the receiver of some harsh criticism by zeddii over beers at ELC San Diego 2016... and we are still closer friends than ever.22:24
moto-timo"meta-c" "meta-go" "meta-rust" "meta-swift" "meta-python" "meta-perl"... zeddii's eyes bleed22:25
* vvn has not been in such conference for a while22:25
zeddiieheheh22:26
* zeddii is language layer triggered!22:26
moto-timo2014 me would like to go back and talk to zeddii22:26
*** GillesM <GillesM!~gilles@105.61.128.77.rev.sfr.net> has quit IRC (Quit: Leaving)22:26
BhsTalelmoto-timo is there a TODO list for crops  ?22:28
vvnsmurray: let me know if you have an idea how to fix wxwidgets with +wayland +opengl -x11 properly ;-)22:28
moto-timoBhsTalel: well, there is the CROPS  product in bugzilla https://bugzilla.yoctoproject.org/describecomponents.cgi?product=CROPS22:29
moto-timoBhsTalel: other than that I guess it would be the issues on the repos in https://github.com/crops22:30
* moto-timo really wishes wxwidgets just worked22:31
BhsTalelThanks , I will take a look22:31
khemsmurray: vvn: I do Not have a no-x11 build on Jenkins or ci I think it’s perhaps good to enable no-gui for all the non-x11 profiles22:32
* moto-timo creates a new garbage collecting memory protected language with trainning wheels: 'zeddii"22:32
moto-timokhem: that is an excellent idea22:33
vvnkhem: I'm trying with no_gui added to distro features. But does "gui" has a special meaning for wxwidgets? Because have wayland but no_gui seems weird22:34
smurraykhem: any thoughts on what the proper fix would be?22:34
* moto-timo contemplates the meaning of "no_gui" when discussing GUI widgets22:34
vvnno_gui does conflict with opengl so it's a no-go22:35
*** BhsTalel44 <BhsTalel44!~BhsTalel@197.2.189.178> has joined #yocto22:36
smurraywell, that's what happens to be in the recipe, we've no idea if that's actually correct until someone looks at wxwidgets22:36
vvnmoto-timo: hence my initial note on a package choosing to handle a "no_gui" feature ;)22:36
smurraymy guess is it's to run against a framebuffer22:37
*** BhsTalel <BhsTalel!~BhsTalel@102.158.48.192> has quit IRC (Ping timeout: 250 seconds)22:38
moto-timovvn: this is like all the GNOME recipes requiring x11 perhaps... don't look behind the curtain22:38
moto-timolol22:38
smurraybut I was out sick today for the most part, and likely won't look at it tomorrow unless I'm feeling a lot better.  Locally I just rolled went back to an older commit to keep the test build I was trying work22:38
smurrays/went//22:38
vvnsmurray: I'm reverting 6c422af now22:39
khemsmurray: I have to look at the code for more insights I am in transit22:43
smurraykhem: k, no worries22:43
BhsTalel44I am newcomer, can anyone share with me the git repo you are working on ? Or where I can follow your work. I am intending to contribute once I understand the patching and committing flow22:44
vvnBhsTalel44: we are discussing a commit which breaks the build if DISTRO_FEATURES has 'wayland opengl' but not 'x11': https://github.com/openembedded/meta-openembedded/commit/6c422af22:47
vvnBhsTalel44: if you have a fix for this (other than reverting it) that'd be a great contribution ;)22:52
BhsTalel44I am trying to understand the issue ...22:56
moto-timoBhsTalel44: we work in many repos, but mostly you are likely to have already been using them to build your Yocto Project based images23:31
moto-timoBhsTalel44: git.yoctoproject.org and git.openembedded.org are the two main trunk servers we use... and then many others which perhaps layers.openembedded.org is a best place to get a feel for the magnitude of the known universe23:32
moto-timoBhsTalel44: we communite mostly via the lists.yoctoproject.org and lists.openembedded.org and then the #yocto and #oe channels on Liberachat.23:33
moto-timos/communite/communicate/23:33
moto-timoBhsTalel44: but many of us have been working together for more than a decade, have met in person over drinks and dinner at conferences, etc. So some unspoken familiarity and sibling teasing happens.23:34
*** BhsTalel44 <BhsTalel44!~BhsTalel@197.2.189.178> has quit IRC (Quit: Client closed)23:36
* vvn watches moto-timo sign-up to yoga classes23:37
moto-timo🤣23:40
moto-timoBack when I was first contributing to OE I did 90-minute _intense_ yoga sessions on Saturday mornings... good times23:46
*** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has quit IRC (Ping timeout: 268 seconds)23:47
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!)23:48
vvnyou can still do it23:57
vvnlive the good old times again23:58

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!