BhsTalel | vvn Yes that is a reasonable idea | 00:02 |
---|---|---|
*** GLumen_ <GLumen_!~Gregory@97-126-1-223.tukw.qwest.net> has quit IRC (Ping timeout: 260 seconds) | 00:03 | |
BhsTalel | amahnui[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 website | 00:06 |
vvn | smurray: 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 cohort | 00: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 #yocto | 00:13 | |
*** BhsTalel <BhsTalel!~BhsTalel@196.229.253.52> has joined #yocto | 00:15 | |
*** davidinux <davidinux!~davidinux@net-188-216-10-245.cust.vodafonedsl.it> has joined #yocto | 00: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 #yocto | 00: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 #yocto | 00: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 #yocto | 00: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 #yocto | 00: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 #yocto | 01: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 #yocto | 01:32 | |
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01: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 #yocto | 01: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 #yocto | 01:53 | |
*** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01: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 #yocto | 02: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 #yocto | 02: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 #yocto | 02:39 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 02: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 #yocto | 02:49 | |
*** akiCA <akiCA!~akiCA@user/akica> has joined #yocto | 02:55 | |
*** amitk <amitk!~amit@103.208.69.67> has joined #yocto | 02: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 #yocto | 02: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 #yocto | 03:02 | |
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 248 seconds) | 03:04 | |
*** BhsTalel <BhsTalel!~BhsTalel@197.1.4.42> has joined #yocto | 03: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 #yocto | 03:14 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 04: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 #yocto | 05: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 #yocto | 05:48 | |
*** marcus_ <marcus_!~marcus@82-209-154-112.cust.bredband2.com> has joined #yocto | 06: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 #yocto | 06:03 | |
*** mike_87 <mike_87!~sgi@cpe90-146-41-24.liwest.at> has joined #yocto | 06:16 | |
*** mike_87 <mike_87!~sgi@cpe90-146-41-24.liwest.at> has left #yocto | 06:17 | |
*** frieder <frieder!~frieder@i59F72C50.versanet.de> has joined #yocto | 06:30 | |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 06:42 | |
*** mckoan|away is now known as mckoan | 06:45 | |
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto | 06: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 #yocto | 06:55 | |
mckoan | marcus_: yes, see yocto multiconfig feature or presentations online | 07:00 |
*** GillesM <GillesM!~gilles@105.61.128.77.rev.sfr.net> has joined #yocto | 07:00 | |
marcus_ | mckoan: thank you | 07: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 image | 07:05 |
*** simonew <simonew!~simonew@2a01:c23:bc18:6600:24f9:148f:c02a:f75b> has joined #yocto | 07:09 | |
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 07:12 | |
LetoThe2nd | marcus_: yes, that is a valid usecase. | 07:12 |
LetoThe2nd | and yo dudX | 07:12 |
LetoThe2nd | for 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 #yocto | 07:26 | |
LetoThe2nd | marcus_: don't see are prohibitive reason. | 07:29 |
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has joined #yocto | 07:32 | |
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has joined #yocto | 07:40 | |
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto | 07: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 #yocto | 07:44 | |
*** Schiller <Schiller!~Schiller@dynamic-002-247-253-148.2.247.pool.telefonica.de> has joined #yocto | 07:45 | |
*** BhsTalel <BhsTalel!~BhsTalel@197.1.4.42> has joined #yocto | 07:56 | |
*** Schiller41 <Schiller41!~Schiller@dynamic-002-247-253-148.2.247.pool.telefonica.de> has joined #yocto | 07: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 #yocto | 07:59 | |
*** manuel_ <manuel_!~manuel198@62.99.131.178> has joined #yocto | 08: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 #yocto | 08:30 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:34 | |
LetoThe2nd | we'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 | |
JaMa | LetoThe2nd: yes, I'm seeing the same, I think global warming is caused by oe-core :) | 08:45 |
LetoThe2nd | JaMa: also no pointer yet? | 08:45 |
RP | I was thinking of trying 22.04 too :/ | 08:50 |
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto | 08:50 | |
LetoThe2nd | RP: 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 |
JaMa | LetoThe2nd: 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 version | 08:51 | |
JaMa | haven't seen gdk-pixbuf error yet | 08:51 |
LetoThe2nd | for 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 | |
LetoThe2nd | JaMa: 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 #yocto | 08:57 | |
qschulz | LetoThe2nd: uninative is enabled by default IIRC | 08:57 |
JaMa | uninative is definitely incompatible with latest 22.04 as mentioned in https://lists.yoctoproject.org/g/yocto/message/56649 | 08:58 |
LetoThe2nd | qschulz: 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 #yocto | 08:59 | |
JaMa | and 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 #yocto | 09:09 | |
dvorkindmitry | why do I have "host contamination" problem? https://pastebin.com/nWWdYY7R | 09:11 |
JaMa | dvorkindmitry: 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 |
JaMa | dvorkindmitry: see https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442 | 09:15 |
JaMa | dvorkindmitry: and "[yocto] KeyError: 'getpwuid(): uid not found: 1000' in do_package phase" thread for more details | 09:15 |
*** GillesMM <GillesMM!~gilles@105.61.128.77.rev.sfr.net> has joined #yocto | 09: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 #yocto | 09:42 | |
dvorkindmitry | JaMa, thank you. but why other libs in other packages are ok for bitbake, althrough they are owned by dv:dv (my localusername)? | 09:48 |
dvorkindmitry | is 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 #yocto | 09:51 | |
rburton | yes | 09:56 |
rburton | makefiles should be using 'install' not cp | 09:56 |
rburton | specifically because it doesn't have the ownership behaviour that cp has | 09: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 #yocto | 10:02 | |
JaMa | dvorkindmitry: if you have to use cp for whatever reason, then use it with --preserve=mode,timestamps | 10:11 |
JaMa | instead of -a | 10:12 |
dvorkindmitry | JaMa, 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 recipe | 10:13 |
JaMa | rburton: 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 #yocto | 10:28 | |
*** Schiller <Schiller!~Schiller@dynamic-002-247-254-056.2.247.pool.telefonica.de> has joined #yocto | 10:33 | |
*** Samiha <Samiha!~Samiha@196.203.207.110> has joined #yocto | 10:49 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 11: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-RRECOMMENDS | 11: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 override | 11:26 |
*** Samiha <Samiha!~Samiha@196.203.207.110> has quit IRC (Quit: Client closed) | 11:45 | |
JaMa | yes it works the same and it should be FILES:${PN}-dev | 11:51 |
JaMa | ':' is override separator used since honister (backwards compatible with dunfell, gatesgarth, hardknott as well if you have recent bitbake revision) | 11:51 |
JaMa | older releases were using '_' as separator | 11:52 |
JaMa | there are some cases where _ is part of variable name (not used as override separator), new syntax makes this more clear | 11:53 |
*** stanf <stanf!~stanf@pr-svc-em1-014.emea.corpinter.net> has joined #yocto | 11:56 | |
RP | JaMa: is it worth asking the opkg maintainer about that? | 12:15 |
JaMa | RP: the = operator in RDEPENDS? I was hoping to get confirmation that this works correctly in rpm | 12:45 |
JaMa | if it's the correct behavior at all | 12:45 |
RP | JaMa: I think it does work in rpm but I guess we should confirm | 12:47 |
JaMa | it happens only for rootfs task with ptest included which might not be covered by autobuilder | 12:48 |
JaMa | ptest and python3-cryptography | 12:48 |
JaMa | kanavin: 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 sense | 12:56 |
kanavin | JaMa, I don't but you can probably undo that change and build to see how it breaks? | 12:57 |
RP | kanavin: btw, I like the idea of that systemd/connman fix, well spotted! | 12:58 |
kanavin | RP: I was hoping to fix this quickly, but connman can't quite be easily convinced to ignore eth0 :-/ | 12:58 |
kanavin | I'm on it | 12:58 |
RP | kanavin: I figured there was some challenge there, thanks! | 12:59 |
kanavin | RP: 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=3015be1e71b99fa1c7da283d84b6c58961c31b33 | 13:00 |
kanavin | good thing i didn't send it blindly | 13: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 now | 13:16 |
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto | 13:17 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 13:20 | |
vvn | kergoth: 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 | |
vvn | smurray: ^ to conclude yesterday's conversation, I think that's how you "cleanly" split your bsp and distro requirements without too much noise. | 13:40 |
RP | kanavin: I'll leave that with you then, thanks! | 13:45 |
kanavin | RP: I figured it out. Apparently some host distro shells write out the above snippet verbatim, e.g. do not convert \n to newlines | 13:46 |
kanavin | I changed that to installing a proper file from SRC_URI | 13:46 |
kanavin | snippet being | 13:46 |
kanavin | echo "[General]\nNetworkInterfaceBlacklist = eth0\n" > ${D}${sysconfdir}/connman/main.conf | 13:46 |
kanavin | fedora 35 is one such | 13:47 |
RP | kanavin: ah, fun. dash vs bash? | 13:47 |
kanavin | RP: possibly, not sure. | 13:47 |
JaMa | /bin/echo helps in cases like this | 13:47 |
RP | kanavin: there is a way to do that more portably with printf iirc but src_uri is easier | 13:48 |
LetoThe2nd | when 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 #yocto | 13:50 | |
JaMa | heh 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 |
RP | LetoThe2nd: if you have write you can just set SSTATE_DIR to there? | 13:52 |
qschulz | LetoThe2nd: 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 #yocto | 13:53 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13:53 | |
zen_coder | Hello, 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 |
LetoThe2nd | RP: qschulz: I always thought this is not allowed for concurrent builds? | 13:55 |
JaMa | locks will prevent overwritting the same file concurrently | 13:55 |
LetoThe2nd | zen_coder: any reason why you went with the meta-toolchain target over an image derived (e)SDK? | 13:55 |
RP | JaMa: no locks for sstate! Just atomic moves | 13:56 |
RP | LetoThe2nd: SSTATE_DIR and DL_DIR are special and can be shared | 13:56 |
JaMa | ah sorry, locks for shared DL_DIR, right? | 13:56 |
LetoThe2nd | RP: ah kay, thanks | 13:56 |
RP | JaMa: yes | 13:56 |
zen_coder | LetoThe2nd: I need a toolchain for cross compilation, as slim as possible. And small enought for me to add necessary package as requested | 13:57 |
JaMa | LetoThe2nd: 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 |
LetoThe2nd | zen_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 |
LetoThe2nd | zen_coder: and then https://docs.yoctoproject.org/ref-manual/variables.html#term-TOOLCHAIN_HOST_TASK applies | 14:05 |
JaMa | RP: 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 it | 14:14 |
rfs613 | when I cherry-pick a fix from master to older branch, do I keep the existing Signed-off-by's ? | 14:18 |
JPEW | rfs613: Yes | 14:18 |
rfs613 | JPEW: thanks! | 14:18 |
*** GLumen_ <GLumen_!~Gregory@97-126-1-223.tukw.qwest.net> has joined #yocto | 14:19 | |
*** GLumen__ <GLumen__!~Gregory@97-126-1-223.tukw.qwest.net> has joined #yocto | 14:20 | |
*** GLumen_ <GLumen_!~Gregory@97-126-1-223.tukw.qwest.net> has quit IRC (Ping timeout: 256 seconds) | 14:24 | |
RP | JaMa: There might even have been a bug opened for that in the last week so I'd love a fix :) | 14:24 |
RP | JaMa: 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 not | 14:25 |
JaMa | the PV dependency is only on PN-ptest package, right? | 14:26 |
RP | JaMa: ah, that would explain it then :) | 14:26 |
RP | JaMa: I was just about to go and look at that | 14:26 |
JaMa | not sure how rpm compares them, but it installed the ptest package even after bumping vectors PR to r1 | 14:28 |
JaMa | the package.manifest close() fix already sent, will try to find bug reference for it | 14:29 |
JaMa | https://bugzilla.yoctoproject.org/show_bug.cgi?id=14772 | 14:29 |
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto | 14: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 #yocto | 14:49 | |
xen77 | Hello | 14: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 #yocto | 14:54 | |
*** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 14: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 #yocto | 15: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 #yocto | 15: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.conf | 15: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 #yocto | 15:07 | |
*** xen38 <xen38!~xen@158.110.165.91> has joined #yocto | 15:08 | |
*** xen38 <xen38!~xen@158.110.165.91> has quit IRC (Client Quit) | 15:10 | |
*** SpicyChimera <SpicyChimera!~SpicyChim@158.110.165.91> has joined #yocto | 15:10 | |
SpicyChimera | Hello everyone. Can I ask you a few questions regarding Yocto? | 15:11 |
vvn | SpicyChimera: don't ask to ask | 15:11 |
jclsn[m] | SpicyChimera: Sure | 15:11 |
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Ping timeout: 272 seconds) | 15:12 | |
SpicyChimera | I'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 |
LetoThe2nd | SpicyChimera: 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 |
LetoThe2nd | SpicyChimera: the keyword is SSTATE here | 15:15 |
rburton | SpicyChimera: you can use package management to just install on the target | 15:16 |
rburton | SpicyChimera: https://docs.yoctoproject.org/dev-manual/common-tasks.html#using-runtime-package-management | 15:16 |
SpicyChimera | Thanks! | 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 #yocto | 15: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_URL | 15: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 #yocto | 15:30 | |
jclsn[m] | No SOURCE_MIRROR_URL should provide the PREMIRRORS, but when I use BB_FETCH_PREMIRRORONLY it doesn't work | 15:33 |
*** SpicyChimera <SpicyChimera!~SpicyChim@158.110.165.91> has quit IRC (Quit: Connection closed) | 15:33 | |
RP | JaMa: I tested with the deb backend and that also shows an error so rpm works, ipk and deb do not | 15: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 work | 15:39 |
RP | JaMa: Looks like this part of the design of debian :( | 15:48 |
RP | JaMa: 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 #yocto | 15:51 | |
dvorkindmitry | I need sys/io.h in SDK. what package generates it? | 15:56 |
*** GLumen__ is now known as GLumen | 15:57 | |
rburton | dvorkindmitry: that's a x86 specific header, so is your target x86? | 15:59 |
dvorkindmitry | rburton, no, it is ARM | 15:59 |
rburton | then your SDK won't have sys/io.h | 15:59 |
*** kevinrowland <kevinrowland!~kevinrowl@165.225.243.0> has joined #yocto | 16:00 | |
manuel_ | I | 16:01 |
*** frieder <frieder!~frieder@i59F72C50.versanet.de> has quit IRC (Remote host closed the connection) | 16:02 | |
kergoth | vvn: 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 another | 16:03 |
vvn | kergoth: 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 |
kergoth | I'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 and | 16:13 |
kergoth | then enables the machine feature, but your call | 16:13 |
*** BhsTalel <BhsTalel!~BhsTalel@197.0.9.173> has joined #yocto | 16:13 | |
vvn | kergoth: 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 |
kergoth | It'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 |
kergoth | This stuff should probably be in a guide to BSP/machine layer construction :) | 16:18 |
kergoth | aka "Vendors: here's how to improve your layers to not be a hot mess" :) | 16:18 |
vvn | there 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 |
vvn | So 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 combined | 16:22 |
kergoth | Yeah, 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 options | 16:22 |
kergoth | afaik | 16:22 |
rburton | RP: 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 |
rburton | its deliberately lean so its something that actually works and can be incrementally expanded over time | 16:23 |
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 16:24 | |
vvn | kergoth: is it safe to reference DISTRO_FEATURES in the machine configuration, given the source order? | 16:24 |
vvn | that seems weird | 16:26 |
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has joined #yocto | 16:26 | |
RP | rburton: did you mention this to zeddii? | 16:27 |
rburton | we've spoken | 16:27 |
rburton | he can veto making it run by default, I haven't sent anything to make that happen yet | 16:28 |
rburton | on-demand runs are still better than what we have currently | 16: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 #yocto | 16: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 #yocto | 16:32 | |
*** gsalazar <gsalazar!~gsalazar@88.157.99.69> has quit IRC (Ping timeout: 260 seconds) | 16:32 | |
RP | Does anyone want to feel really ill? https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/t222 | 16:34 |
RP | JaMa, rburton: "fix" for the python3-crypto issue on deb/ipk | 16:34 |
RP | ^^^ | 16:34 |
rburton | ewww | 16:34 |
rburton | the alternative is to revert the dependency | 16:35 |
rburton | i was just trying to be clever | 16:35 |
RP | rburton: it doesn't change the fact that this is just broken | 16:35 |
* RP wishes he had some better idea but this was the best I could come up with | 16:36 | |
kergoth | vvn: 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, though | 16:37 |
RP | rburton: -helper change added | 16:40 |
RP | rburton: when you say "enable for master runs", you mean a-full? | 16:41 |
rburton | yes | 16:41 |
RP | rburton: will be interesting to only do that on master. We'd need to remove the meta-virt entry from the other helper branches | 16:41 |
RP | rburton: I'm not even trying to make something "only master" in the autobuilder2 code | 16:42 |
rburton | hah fair enough | 16:42 |
rburton | well the change i did was low impact and should be easily backported... | 16:43 |
rburton | now to figure out why testimage doesn't work | 16:43 |
RP | rburton: I guess that is for me to try then? :) | 16:44 |
rburton | not at all | 16:44 |
zen_coder | LetoThe2nd: 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 |
BhsTalel | Thanks | 16:45 |
zen_coder | I mean TOOLCHAIN_TARGET_TASK | 16:45 |
RP | rburton: it doesn't cherry-pick to hardknott FWIW, it does to honister | 16:45 |
RP | BhsTalel: it allows you to share native sstate between different distros and OSes | 16:54 |
BhsTalel | RP So if I want native builds run faster I include uninative in my distro ? | 17:00 |
zen_coder | what are the package names in yocto for X11 and OpenGL? I need to add the Qt depedencies to make toolchain | 17: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 | |
rfs613 | also any pointers to articles/blog/FAQ about tools to manage the repos (repo/kas/etc) would be appreciated | 17:08 |
rburton | i find kas a lot easier than repo for controlled builds | 17:13 |
*** florian <florian!~florian@dynamic-093-133-184-188.93.133.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 17:13 | |
rburton | but for local hacking, i have hand-controlled repos because that's easier | 17:13 |
rfs613 | hmm 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 |
vvn | kergoth: 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 |
BhsTalel | For local work, hand-controlled repos are easier, for automation I think KAS is okay, but I think repo provides more control | 17:15 |
rfs613 | I could script this I suppose but it seems like it is common enough situation that there should be an obvious solution | 17:15 |
rburton | if 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 anything | 17:16 |
vvn | rfs613: 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 |
rburton | you've not really said what your goal is though, so it's hard to comment | 17:17 |
rburton | for local hacking i have hand controlled branches because its only occasionally that they're actually on upstream branches, normally they're on local feature branches | 17:17 |
vvn | The repo patching is huge for me and it's why I stick with kas, even though it has its flaws. | 17:17 |
rfs613 | rburton: true, I have not been very specific, because I am mentally still trying to figure it out ;-) | 17:18 |
rfs613 | but take for example the vim update patch which i posted today and then realized RP already did it. | 17:18 |
sotaoverride | how do we tell the am image recipe to make a rootfs read only? | 17:18 |
rfs613 | normally I have been searchign CVEs in the mailing lists to see if they are addressed on dunfell. | 17:18 |
sotaoverride | tell an* | 17:18 |
rburton | sotaoverride: https://docs.yoctoproject.org/search.html?q=read+only+rootfs&check_keywords=yes&area=default | 17:19 |
rfs613 | but this one got fixed in stable/dunfell-nut without any emails it seems, so I didn't see it. | 17:19 |
rburton | rfs613: that's staging so just a race condition between you posting it and the author posting it | 17:19 |
rfs613 | rburton: well in this case it landed 2 days ago, but in a branch I didn't really look at. | 17:20 |
rburton | sotaoverride: leads to https://docs.yoctoproject.org/dev-manual/common-tasks.html#creating-a-read-only-root-filesystem | 17: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 |
rfs613 | I wonder if someone has collected pro/con lists for each of these approaches. | 17:22 |
vvn | rfs613: 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 |
rburton | rfs613: 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 testing | 17:28 |
kergoth | kas really needs to get the ability to load plugins from layers at some point, that'd open up a lot of flexibility | 17:28 |
rburton | kergoth: it used to, paulbarker removed it :) | 17:29 |
rburton | i also want to add it back | 17:29 |
BhsTalel | I 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 |
rburton | kergoth: my imaginary fork of kas has out-of-tree plugin support | 17:29 |
kergoth | heh :) | 17:29 |
rburton | BhsTalel: 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 |
vvn | yeah but kas as a strong bias on reproducibility, so loading plugins, out-of-tree stuffs etc. isn't gonna happen | 17:30 |
kergoth | I don't think that would prevent reproducibility | 17:31 |
kergoth | having the ability to add new commands for your product or distro would be invaluable | 17:31 |
vvn | I 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 why | 17:31 |
vvn | ho and I use kas for its container too, I'm never building yocto on my host machine. | 17:32 |
BhsTalel | For my projects I always choose between `repo` or `git submodules` for developers, after that one KAS file is used for the pipeline. | 17:32 |
vvn | Given the bitbake built-in fetcher, supporting patches and all, it's too bad that we cannot come up with a layer.bbclass or something | 17:33 |
vvn | describing source, patches, dependencies to other layers, all that using usual bitbake recipes. | 17:34 |
kergoth | vvn: 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 setup | 17:34 |
kergoth | oe-lite was the project | 17:34 |
kergoth | I always rather liked that idea | 17:35 |
kergoth | then 'oe build', etc called out to the underlying bits that it cloned before | 17:35 |
kergoth | oe clone git://foo && cd foo && oe build foo; or the like | 17:35 |
kergoth | vvn: there's an item in the yocto proejct future dirctions page to address this, providing a definitive mechanism for layer cloning and management | 17:36 |
kergoth | but it's non-trivial and requires knowledge of both project history and the use cases and alternative projects | 17:36 |
kergoth | but it's a known gap | 17:37 |
kergoth | https://wiki.yoctoproject.org/wiki/Future_Directions#Layer_setup.2Fconfiguration | 17:37 |
vvn | I totally understand that it's a tricky topic | 17:37 |
vvn | but I would still love to see all these OE-Core crappy init env scripts gone :) | 17:38 |
kergoth | I 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 else | 17:38 |
kergoth | I do think the plugin capability is going to be key to allow for such extension | 17:38 |
*** mckoan is now known as mckoan|away | 17:39 | |
rfs613 | for 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 |
kergoth | I 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 extensible | 17:39 |
*** BhsTalel30 <BhsTalel30!~BhsTalel@197.2.30.112> has joined #yocto | 17:39 | |
kergoth | yep, it's a definite barrier and adds to our already steep learnign curve ;) | 17:40 |
vvn | kergoth: 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 |
vvn | kergoth: yeah but forcing the use of local.conf only, forcing the non-bitbake syntax, it just abstracts bitbake too much | 17:41 |
kergoth | I 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 kas | 17:41 |
vvn | it'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 #yocto | 17:41 | |
kergoth | Yeah, that's a good point. Encourages a lack of knowledge of the underlying tools | 17:42 |
kergoth | Too much | 17:42 |
BhsTalel30 | I 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 |
BhsTalel30 | SERVICE_FILES[systemd] = "example.service" | 17:42 |
BhsTalel30 | SERVICE_FILES[pkgname.systemd] = "otherexample.service" | 17:42 |
kergoth | Adding ease of use is one thing, but you can't avoid learning the underlying tooling | 17:42 |
BhsTalel30 | SERVICE_FILES[sysvinit] ... | 17:42 |
BhsTalel30 | I already done the systemd part | 17:42 |
BhsTalel30 | What do you think ? | 17:42 |
*** BhsTalel <BhsTalel!~BhsTalel@197.0.9.173> has quit IRC (Ping timeout: 250 seconds) | 17:42 | |
vvn | I 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 |
kergoth | I 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, even | 17:43 |
kergoth | i.e. 'oe build target' prints '> bitbake target' after setting up the environment | 17:43 |
kergoth | just to avoid the need to source something into your current shell | 17:44 |
kergoth | (if desired) | 17:44 |
kergoth | but it should be additional, not required | 17:44 |
*** BhsTalel <BhsTalel!~BhsTalel@102.158.48.192> has joined #yocto | 17:45 | |
kergoth | i'd like to see proper completions generation and stuff too. `eval $(oe init zsh); bitbake foo` | 17:45 |
kergoth | no reason it couldnt do that at the same time it adjusts PATH and all | 17:45 |
vvn | kergoth: 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 |
kergoth | actually 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 like | 17:47 |
*** BhsTalel30 <BhsTalel30!~BhsTalel@197.2.30.112> has quit IRC (Ping timeout: 250 seconds) | 17:47 | |
kergoth | ugh yes there's a fair bit of necessary boilerplate with kas that'd be nice to avoid | 17:48 |
vvn | exactly | 17:48 |
kergoth | just assume the project config path if it's not explicitly set, etc | 17:48 |
* rfs613 starts a list of the tools, with pro/cons. Very preliminary at this point... https://docs.google.com/document/d/1lUERORP3PTq7JuygRabVBxUYDYfvAST8bIh5b7gi1Kk | 17:49 | |
vvn | BhsTalel: 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 | |
BhsTalel | vvn 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` also | 18: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 #yocto | 18: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 #yocto | 18:32 | |
*** manuel_ <manuel_!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto | 18:48 | |
rfs613 | kergoth: 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 | |
kergoth | It doesn't exist, we're brainstorming | 18:59 |
rfs613 | ah, very good | 18:59 |
kergoth | were talkinga bout theoretical alternatives for layer adn repo management and configuration | 19:00 |
*** vvn <vvn!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has joined #yocto | 19:00 | |
rfs613 | ok, 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 |
BhsTalel | Maybe 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 |
BhsTalel | So, just the developer needs to clone poky only, and then pass the conf file for it. | 19:03 |
dvorkindmitry | pulled latest "dunfell" branch and got strange "m4-native" recipe build error: https://pastebin.com/jTcSTQK3 | 19:09 |
*** marc3 <marc3!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has quit IRC (Quit: WeeChat 3.4) | 19:09 | |
rfs613 | dvorkindmitry: not much help to you, but I'm on dunfell with same m4-native/1.4.18-r0, no issues building it | 19:11 |
dvorkindmitry | rfs613, so probably some host incompatibility? hmmm... | 19:12 |
rfs613 | dvorkindmitry: 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 #yocto | 19:15 | |
rfs613 | https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html#build-host-packages | 19:15 |
rfs613 | actually there's a better link in the reference manual | 19:15 |
*** marc2 <marc2!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has joined #yocto | 19:17 | |
fabian | ERROR: 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 |
fabian | Hi 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 |
rfs613 | fabian: 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 |
fabian | Ok 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 #yocto | 19: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 #yocto | 19: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 #yocto | 19:35 | |
*** florian <florian!~florian@dynamic-093-133-184-188.93.133.pool.telefonica.de> has joined #yocto | 20: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 #yocto | 20:09 | |
*** fabian <fabian!~fabian@187.56.88.38> has quit IRC (Quit: Client closed) | 20:20 | |
smurray | khem: 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 |
smurray | khem: 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 #yocto | 21: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 com | 22:00 | |
vvn | smurray: lol I came to the channel to mention exactly this... Having the same no_gui issue | 22:00 |
moto-timo | zeddii: your warranty for your car has expired! Urgent! You must buy new coverage! | 22:01 |
vvn | btw is this a standard distro feature or yet another arbitrary chosen feature from a package? | 22:01 |
moto-timo | vvn: 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 |
vvn | moto-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.org | 22:04 |
vvn | moto-timo: nothing to take personal here :) | 22:05 |
moto-timo | vvn: my skin has grown very thick in the last decade. | 22:05 |
vvn | I guess it's a good thing | 22:05 |
moto-timo | vvn: 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 mood | 22:07 | |
vvn | layers.openembedded.org is very nice, I use it all the time to look recipes location or have a quick web view of the source | 22:07 |
vvn | moto-timo: and here you assume that everyone who complains don't contribute back. Nice. | 22:08 |
vvn | Sure that skin is that thick? ;) | 22:08 |
moto-timo | vvn: thick skin still exudes some bodily fluids | 22:09 |
*** dvorkindmitry <dvorkindmitry!~dv@5.167.98.73> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/) | 22:10 | |
moto-timo | I 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-timo | Like many of our core infrastructure tools, we do not have a maintainer. period. | 22:11 |
moto-timo | Any code left alone for 2+ years will bit rot. This I can assure you. | 22:12 |
vvn | moto-timo: hmm sorry if 'arbitrary chosen feature' pissed you off initially, but I don't really see the point you're trying to make here | 22:15 |
zeddii | moto-timo. I deserved that troll!! | 22:15 |
moto-timo | vvn: very simple. you use layers.openembedded.org. How is that being kept alive? | 22:16 |
moto-timo | zeddii: yup.. trolling happens and is normal. | 22:16 |
* moto-timo is being trolled now. | 22:16 | |
vvn | moto-timo: ok but why the attack about the layer index? | 22:16 |
zeddii | ahah buggers. are using my bad email address on that thread. Now I'm getting to enjoy all the bounces. | 22:17 |
moto-timo | vvn: 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-timo | zeddii: I am going to start selling you insurance on all your emails. | 22:18 |
* moto-timo sighs and thinks about cocktails. | 22:18 | |
zeddii | vvn. 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 |
zeddii | in 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 cocktails | 22:20 | |
zeddii | moto-timo. do you have push privs ? I'd say "ship it!" :) | 22:20 |
moto-timo | SHIP IT | 22:20 |
moto-timo | I also have super secret privs to burn down the instance. | 22:21 |
* moto-timo will not ever do that intentionally. | 22:21 | |
moto-timo | Also, CROPS. do you use it? guess who maintains it? | 22:22 |
* moto-timo should _really_ shut up now. | 22:22 | |
vvn | zeddii: 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-timo | IRC has absolutely no nuance of body language or tone... we only have that because we meet IRL at conferences. | 22:23 |
moto-timo | I 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 bleed | 22:25 |
* vvn has not been in such conference for a while | 22:25 | |
zeddii | eheheh | 22:26 |
* zeddii is language layer triggered! | 22:26 | |
moto-timo | 2014 me would like to go back and talk to zeddii | 22:26 |
*** GillesM <GillesM!~gilles@105.61.128.77.rev.sfr.net> has quit IRC (Quit: Leaving) | 22:26 | |
BhsTalel | moto-timo is there a TODO list for crops ? | 22:28 |
vvn | smurray: let me know if you have an idea how to fix wxwidgets with +wayland +opengl -x11 properly ;-) | 22:28 |
moto-timo | BhsTalel: well, there is the CROPS product in bugzilla https://bugzilla.yoctoproject.org/describecomponents.cgi?product=CROPS | 22:29 |
moto-timo | BhsTalel: other than that I guess it would be the issues on the repos in https://github.com/crops | 22:30 |
* moto-timo really wishes wxwidgets just worked | 22:31 | |
BhsTalel | Thanks , I will take a look | 22:31 |
khem | smurray: 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 profiles | 22:32 |
* moto-timo creates a new garbage collecting memory protected language with trainning wheels: 'zeddii" | 22:32 | |
moto-timo | khem: that is an excellent idea | 22:33 |
vvn | khem: 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 weird | 22:34 |
smurray | khem: any thoughts on what the proper fix would be? | 22:34 |
* moto-timo contemplates the meaning of "no_gui" when discussing GUI widgets | 22:34 | |
vvn | no_gui does conflict with opengl so it's a no-go | 22:35 |
*** BhsTalel44 <BhsTalel44!~BhsTalel@197.2.189.178> has joined #yocto | 22:36 | |
smurray | well, that's what happens to be in the recipe, we've no idea if that's actually correct until someone looks at wxwidgets | 22:36 |
vvn | moto-timo: hence my initial note on a package choosing to handle a "no_gui" feature ;) | 22:36 |
smurray | my guess is it's to run against a framebuffer | 22:37 |
*** BhsTalel <BhsTalel!~BhsTalel@102.158.48.192> has quit IRC (Ping timeout: 250 seconds) | 22:38 | |
moto-timo | vvn: this is like all the GNOME recipes requiring x11 perhaps... don't look behind the curtain | 22:38 |
moto-timo | lol | 22:38 |
smurray | but 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 work | 22:38 |
smurray | s/went// | 22:38 |
vvn | smurray: I'm reverting 6c422af now | 22:39 |
khem | smurray: I have to look at the code for more insights I am in transit | 22:43 |
smurray | khem: k, no worries | 22:43 |
BhsTalel44 | I 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 flow | 22:44 |
vvn | BhsTalel44: 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/6c422af | 22:47 |
vvn | BhsTalel44: if you have a fix for this (other than reverting it) that'd be a great contribution ;) | 22:52 |
BhsTalel44 | I am trying to understand the issue ... | 22:56 |
moto-timo | BhsTalel44: we work in many repos, but mostly you are likely to have already been using them to build your Yocto Project based images | 23:31 |
moto-timo | BhsTalel44: 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 universe | 23:32 |
moto-timo | BhsTalel44: we communite mostly via the lists.yoctoproject.org and lists.openembedded.org and then the #yocto and #oe channels on Liberachat. | 23:33 |
moto-timo | s/communite/communicate/ | 23:33 |
moto-timo | BhsTalel44: 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 classes | 23:37 | |
moto-timo | 🤣 | 23:40 |
moto-timo | Back when I was first contributing to OE I did 90-minute _intense_ yoga sessions on Saturday mornings... good times | 23: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 | |
vvn | you can still do it | 23:57 |
vvn | live the good old times again | 23:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!