| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 00:26 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 246 seconds) | 00:28 | |
| *** camus1 is now known as camus | 00:28 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection) | 00:32 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 00:34 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Ping timeout (120 seconds)) | 01:28 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has joined #yocto | 01:32 | |
| *** rber|res <rber|res!~rber|res@ppp-2-86-132-26.home.otenet.gr> has quit IRC (Ping timeout: 246 seconds) | 01:34 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 01:58 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 264 seconds) | 02:00 | |
| *** camus1 is now known as camus | 02:00 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has quit IRC (Remote host closed the connection) | 02:26 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has joined #yocto | 02:28 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 02:29 | |
| *** mranostaj <mranostaj!~mranostaj@185.193.126.133> has quit IRC (Ping timeout: 245 seconds) | 02:37 | |
| *** mranostaj <mranostaj!~mranostaj@97-120-53-30.ptld.qwest.net> has joined #yocto | 02:37 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 02:40 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has quit IRC (Remote host closed the connection) | 02:54 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has joined #yocto | 02:57 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 246 seconds) | 02:57 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 02:58 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has quit IRC (Remote host closed the connection) | 03:01 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has joined #yocto | 03:11 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has quit IRC (Ping timeout: 265 seconds) | 03:16 | |
| *** jmiehe1 <jmiehe1!~Thunderbi@user/jmiehe> has joined #yocto | 03:26 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 246 seconds) | 03:27 | |
| *** jmiehe1 is now known as jmiehe | 03:27 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has joined #yocto | 03:31 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has quit IRC (Remote host closed the connection) | 03:33 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has joined #yocto | 03:34 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has quit IRC (Remote host closed the connection) | 03:34 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has joined #yocto | 03:34 | |
| *** amitk <amitk!~amit@103.208.71.3> has joined #yocto | 04:04 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 04:14 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 265 seconds) | 04:16 | |
| *** camus1 is now known as camus | 04:16 | |
| *** oobitots <oobitots!~oobitots@aer01-mda1-dmz-wsa-2.cisco.com> has joined #yocto | 04:48 | |
| *** RobertBerger <RobertBerger!~rber|res@ppp-2-86-132-26.home.otenet.gr> has quit IRC (Ping timeout: 246 seconds) | 05:06 | |
| *** rber|res <rber|res!~rber|res@ppp-2-86-135-193.home.otenet.gr> has joined #yocto | 05:08 | |
| *** oobitots34 <oobitots34!~oobitots@46.211.68.10> has joined #yocto | 05:39 | |
| *** ThomasD13 <ThomasD13!~thomasd13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 05:43 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 05:43 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 245 seconds) | 05:45 | |
| *** camus1 is now known as camus | 05:45 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 05:47 | |
| *** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has quit IRC (Ping timeout: 252 seconds) | 05:48 | |
| *** Sion <Sion!~dev@D584BE1E.static.ziggozakelijk.nl> has joined #yocto | 05:50 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 05:52 | |
| *** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 05:56 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-07-184-145-217-104.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.3-dev) | 05:59 | |
| *** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has joined #yocto | 06:11 | |
| *** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has quit IRC (Read error: Connection reset by peer) | 06:14 | |
| *** mattsm <mattsm!~mattsm@104-181-154-57.lightspeed.austtx.sbcglobal.net> has joined #yocto | 06:14 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Remote host closed the connection) | 06:16 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 06:16 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 06:17 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 264 seconds) | 06:18 | |
| *** camus1 is now known as camus | 06:18 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 06:21 | |
| *** oobitots34 <oobitots34!~oobitots@46.211.68.10> has quit IRC (Ping timeout: 256 seconds) | 06:21 | |
| *** tre <tre!~tre@ip5f588630.dynamic.kabel-deutschland.de> has joined #yocto | 06:22 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 06:22 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 265 seconds) | 06:25 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Client Quit) | 06:25 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 06:33 | |
| *** ant__ <ant__!~ant@host-82-54-240-7.retail.telecomitalia.it> has quit IRC (Quit: Leaving) | 06:36 | |
| JosefHolzmayrThe | cyo dudX | 06:38 |
|---|---|---|
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 06:42 | |
| *** mckoan|away is now known as mckoan | 06:45 | |
| mckoan | good morning | 06:45 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 06:47 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 06:47 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 06:49 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 06:50 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Client Quit) | 06:51 | |
| *** frieder <frieder!~frieder@i59F4BCD2.versanet.de> has joined #yocto | 06:51 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 06:51 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 06:52 | |
| *** fbre <fbre!~fbre@145.253.222.69> has joined #yocto | 06:58 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.135> has joined #yocto | 06:58 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:01 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 250 seconds) | 07:01 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 07:01 | |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 07:10 | |
| *** davidinux <davidinux!~davidinux@net-2-34-77-16.cust.vodafonedsl.it> has quit IRC (Ping timeout: 246 seconds) | 07:19 | |
| *** davidinux <davidinux!~davidinux@84.17.59.156> has joined #yocto | 07:19 | |
| *** dev1990 <dev1990!~dev@78.10.71.240> has quit IRC (Quit: Konversation terminated!) | 07:20 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 07:56 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 07:56 | |
| qschulz | o/ | 08:09 |
| *** BuZZ-T <BuZZ-T!~basti@213.188.127.94> has joined #yocto | 08:11 | |
| BuZZ-T | hi.. i just started working with extensible sdk for the first time, usually i used the complete yocto system. when i used the yocto system i generated a complete sysroot with "bitbake build-sysroots". Can i achieve the same in the eSDK? i'd like to prefer only one sysroot that contains everything for my development. | 08:15 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 08:16 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** scjg <scjg!~scjgmatri@2001:470:69fc:105::f5d6> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** kayterina[m] <kayterina[m]!~kayterina@2001:470:69fc:105::960> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** PascalBach[m] <PascalBach[m]!~bachpmatr@2001:470:69fc:105::1d3b> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** barath <barath!~barath@2001:470:69fc:105::21a> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** k4wsys[m] <k4wsys[m]!~k4wsysmat@2001:470:69fc:105::e339> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** CarlesFernandez[ <CarlesFernandez[!~cfernande@2001:470:69fc:105::e590> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** twinning[m] <twinning[m]!~twinningm@2001:470:69fc:105::e5db> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** janvermaete[m] <janvermaete[m]!~vermaetem@2001:470:69fc:105::ee7> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** olani[m] <olani[m]!~olanimatr@2001:470:69fc:105::c93> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** JosefHolzmayrThe <JosefHolzmayrThe!~theyoctoj@2001:470:69fc:105::e785> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** SalamaSalama[m] <SalamaSalama[m]!~moustafa5@2001:470:69fc:105::e6c4> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** Jari[m] <Jari[m]!~jarihmatr@2001:470:69fc:105::6a7> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** hpsy[m] <hpsy[m]!~hpsymatri@2001:470:69fc:105::f822> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** ezzuldin[m] <ezzuldin[m]!~ezzuldinm@2001:470:69fc:105::f386> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** DanielWalls[m] <DanielWalls[m]!~dwallsmat@2001:470:69fc:105::ff37> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** michaelo[m] <michaelo[m]!~michael-o@2001:470:69fc:105::be7c> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** jaskij[m] <jaskij[m]!~jaskijmat@2001:470:69fc:105::fa76> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** coldspark29[m] <coldspark29[m]!~coldspar_@2001:470:69fc:105::db09> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** Alban[m] <Alban[m]!~albeugaen@2001:470:69fc:105::34b4> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** Nate[m]1 <Nate[m]1!~nsdrudema@2001:470:69fc:105::f855> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** etam[m] <etam[m]!~etam@user/etam> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** ramprakash[m] <ramprakash[m]!~ramprakas@2001:470:69fc:105::fbfe> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** azstevep[m] <azstevep[m]!~azstevepm@2001:470:69fc:105::1:3b7> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** cryptollision[m] <cryptollision[m]!~cryptolli@2001:470:69fc:105::f778> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** saYco[m] <saYco[m]!~saycomatr@2001:470:69fc:105::1:2a0> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** agherzan <agherzan!~agherzan@2001:470:69fc:105::e1fe> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** xicopitz[m] <xicopitz[m]!~xicopitzm@2001:470:69fc:105::4869> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** glembo[m] <glembo[m]!~glembomat@2001:470:69fc:105::174> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** Spectrejan[m] <Spectrejan[m]!~spectreja@2001:470:69fc:105::1609> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** Markus[m]1 <Markus[m]1!~markus5hm@2001:470:69fc:105::ed4f> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** fabatera[m] <fabatera[m]!~fabateram@2001:470:69fc:105::18d5> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** khem <khem!~khemmatri@2001:470:69fc:105::b81> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** berton[m] <berton[m]!~berton@2001:470:69fc:105::ce36> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** Barry[m]1 <Barry[m]1!~barryriot@2001:470:69fc:105::900> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** jonesv[m] <jonesv[m]!~jonesv@2001:470:69fc:105::4616> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| *** jordemort <jordemort!~jordemort@2001:470:69fc:105::2d9> has quit IRC (Quit: Bridge terminating on SIGTERM) | 08:22 | |
| kanavin | BuZZ-T, eSDK is basically the same yocto system with a pre-built sstate and toolchain, so yes | 08:24 |
| *** jordemort <jordemort!~jordemort@2001:470:69fc:105::2d9> has joined #yocto | 08:25 | |
| *** etam[m] <etam[m]!~etam@user/etam> has joined #yocto | 08:25 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:25 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 08:26 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:26 | |
| BuZZ-T | kanavin: ok.. good to know, do have any idea how to generate the "complete" sysroot? like bitbake build-sysroots has done in the "normal" yocto system | 08:27 |
| *** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto | 08:27 | |
| *** frieder_ <frieder_!~frieder@i59F4BCD2.versanet.de> has joined #yocto | 08:27 | |
| *** Alban[m] <Alban[m]!~albeugaen@2001:470:69fc:105::34b4> has joined #yocto | 08:27 | |
| *** Spectrejan[m] <Spectrejan[m]!~spectreja@2001:470:69fc:105::1609> has joined #yocto | 08:27 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 08:28 | |
| *** scjg <scjg!~scjgmatri@2001:470:69fc:105::f5d6> has joined #yocto | 08:28 | |
| *** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has joined #yocto | 08:28 | |
| *** kayterina[m] <kayterina[m]!~kayterina@2001:470:69fc:105::960> has joined #yocto | 08:28 | |
| *** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has joined #yocto | 08:28 | |
| *** khem <khem!~khemmatri@2001:470:69fc:105::b81> has joined #yocto | 08:28 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #yocto | 08:28 | |
| kanavin | BuZZ-T, devtool has a command to rebuild the target image it's based on | 08:28 |
| *** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has joined #yocto | 08:28 | |
| *** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has joined #yocto | 08:28 | |
| *** frieder <frieder!~frieder@i59F4BCD2.versanet.de> has quit IRC (Ping timeout: 245 seconds) | 08:28 | |
| *** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has joined #yocto | 08:28 | |
| *** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has joined #yocto | 08:29 | |
| *** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto | 08:29 | |
| *** jonesv[m] <jonesv[m]!~jonesv@2001:470:69fc:105::4616> has joined #yocto | 08:29 | |
| *** azstevep[m] <azstevep[m]!~azstevepm@2001:470:69fc:105::1:3b7> has joined #yocto | 08:29 | |
| *** PascalBach[m] <PascalBach[m]!~bachpmatr@2001:470:69fc:105::1d3b> has joined #yocto | 08:29 | |
| kanavin | what does build-sysroots really do? | 08:29 |
| *** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has joined #yocto | 08:29 | |
| *** CarlesFernandez[ <CarlesFernandez[!~cfernande@2001:470:69fc:105::e590> has joined #yocto | 08:30 | |
| *** k4wsys[m] <k4wsys[m]!~k4wsysmat@2001:470:69fc:105::e339> has joined #yocto | 08:30 | |
| *** coldspark29[m] <coldspark29[m]!~coldspar_@2001:470:69fc:105::db09> has joined #yocto | 08:30 | |
| *** barath <barath!~barath@2001:470:69fc:105::21a> has joined #yocto | 08:30 | |
| *** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has joined #yocto | 08:30 | |
| *** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has joined #yocto | 08:30 | |
| *** Nate[m]1 <Nate[m]1!~nsdrudema@2001:470:69fc:105::f855> has joined #yocto | 08:30 | |
| BuZZ-T | kanavin: ok, thank you. i'll give it a try | 08:30 |
| *** glembo[m] <glembo[m]!~glembomat@2001:470:69fc:105::174> has joined #yocto | 08:30 | |
| *** Barry[m] <Barry[m]!~barryriot@2001:470:69fc:105::900> has joined #yocto | 08:30 | |
| *** twinning[m] <twinning[m]!~twinningm@2001:470:69fc:105::e5db> has joined #yocto | 08:31 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has joined #yocto | 08:31 | |
| *** DanielWalls[m] <DanielWalls[m]!~dwallsmat@2001:470:69fc:105::ff37> has joined #yocto | 08:31 | |
| *** Jari[m] <Jari[m]!~jarihmatr@2001:470:69fc:105::6a7> has joined #yocto | 08:31 | |
| *** fabatera[m] <fabatera[m]!~fabateram@2001:470:69fc:105::18d5> has joined #yocto | 08:31 | |
| kanavin | BuZZ-T, the thing is, build-sysroots is not supposed to be used as a standalone target, so isn't really supported | 08:31 |
| *** agherzan <agherzan!~agherzan@2001:470:69fc:105::e1fe> has joined #yocto | 08:31 | |
| kanavin | BuZZ-T, if you want a complete sysroot, making an image is better | 08:31 |
| *** ezzuldin[m] <ezzuldin[m]!~ezzuldinm@2001:470:69fc:105::f386> has joined #yocto | 08:31 | |
| *** JosefHolzmayrThe <JosefHolzmayrThe!~theyoctoj@2001:470:69fc:105::e785> has joined #yocto | 08:32 | |
| *** xicopitz[m] <xicopitz[m]!~xicopitzm@2001:470:69fc:105::4869> has joined #yocto | 08:32 | |
| *** ramprakash[m] <ramprakash[m]!~ramprakas@2001:470:69fc:105::fbfe> has joined #yocto | 08:32 | |
| *** janvermaete[m] <janvermaete[m]!~vermaetem@2001:470:69fc:105::ee7> has joined #yocto | 08:32 | |
| *** Markus[m]1 <Markus[m]1!~markus5hm@2001:470:69fc:105::ed4f> has joined #yocto | 08:32 | |
| *** cryptollision[m] <cryptollision[m]!~cryptolli@2001:470:69fc:105::f778> has joined #yocto | 08:33 | |
| kanavin | but I need to understand your use case. What's your development workflow? | 08:33 |
| *** olani[m] <olani[m]!~olanimatr@2001:470:69fc:105::c93> has joined #yocto | 08:33 | |
| *** SalamaSalama[m] <SalamaSalama[m]!~moustafa5@2001:470:69fc:105::e6c4> has joined #yocto | 08:33 | |
| *** michaelo[m] <michaelo[m]!~michael-o@2001:470:69fc:105::be7c> has joined #yocto | 08:33 | |
| *** berton[m] <berton[m]!~berton@2001:470:69fc:105::ce36> has joined #yocto | 08:33 | |
| *** jaskij[m] <jaskij[m]!~jaskijmat@2001:470:69fc:105::fa76> has joined #yocto | 08:34 | |
| *** hpsy[m] <hpsy[m]!~hpsymatri@2001:470:69fc:105::f822> has joined #yocto | 08:34 | |
| *** saYco[m] <saYco[m]!~saycomatr@2001:470:69fc:105::1:2a0> has joined #yocto | 08:34 | |
| *** dkl <dkl!~dkl@prometheus.umask.eu> has quit IRC (Quit: %quit%) | 08:35 | |
| *** dkl <dkl!~dkl@prometheus.umask.eu> has joined #yocto | 08:36 | |
| BuZZ-T | kanavin: in the past i used the complete yocto system.. i've done development in eclipse. I build the sysroot with "bitbake build-sysroots" and included the generated include folder (as link) to my eclipse projects. now we were running a newer version (dunfell) that doesn't have that eclipse plugin anymore. and i'm also playing arround with visual studio code. | 08:38 |
| kanavin | BuZZ-T, I think you need to first study the standard devtool workflows that eSDK provides | 08:39 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 08:39 | |
| kanavin | build-sysroots isn't supported outside of internal uses of it | 08:39 |
| kanavin | eclipse plugin was dropped because no one wanted to maintain it (and still no one does), so if you come up with some kind of IDE support and agree to keep it working, that'd be most welcome | 08:40 |
| BuZZ-T | kanavin: eclipse is still usable without the plugin. but the workflow does change a little bit. when i use a normal sdk (-c populate_sdk), source the environment from, do ./configure $CONFIGURE_FLAGS (we use autotools based projects) and start eclipse from the shell, i can do pretty much all of my development. the only manual tweak needs to be done is setting the right debugger in the debug configuration. | 08:45 |
| kanavin | BuZZ-T, you can do the same with eSDK, but eSDK adds the sstate cache, layers, devtool and bitbake (indirectly, only via devtool) | 08:46 |
| *** rber|res <rber|res!~rber|res@ppp-2-86-135-193.home.otenet.gr> has quit IRC (Remote host closed the connection) | 08:47 | |
| *** rber|res <rber|res!~rber|res@ppp-2-86-135-193.home.otenet.gr> has joined #yocto | 08:47 | |
| JosefHolzmayrThe | kanavin: RP: does this ring a bell? do we have comparable data that wecould put into a chart? https://twitter.com/ReproBuilds/status/1442479184618610692 | 08:48 |
| kanavin | JosefHolzmayrThe, https://www.yoctoproject.org/reproducible-build-results/ | 08:49 |
| BuZZ-T | kanavin: ok. thank you again.. i'll play a bit arround with eSDK :) | 08:49 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 08:51 | |
| kanavin | JosefHolzmayrThe, dare I suggest, Debian's chart is not that impressive. The amount of non-repro packages is not going down. | 08:51 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 08:51 | |
| JosefHolzmayrThe | kanavin: thx | 08:52 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 245 seconds) | 08:52 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 08:52 | |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Ping timeout: 265 seconds) | 08:53 | |
| JosefHolzmayrThe | kanavin: you may suggest anything, but I will probably not pass it along. advocacy is not meant to make others look bad. ;-) | 08:55 |
| JosefHolzmayrThe | (the question was not for me personally) | 08:55 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 09:06 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 09:07 | |
| ThomasD13 | Hi, I have a new (hardware) machine to build my stuff with yocto. I have a bit of DDR4 memory - are there any tricks to further speedup the build-process with yocto? | 09:08 |
| kanavin | ThomasD13, add CPU cores | 09:09 |
| ThomasD13 | I think its not possible to use DDR4 memory as ramdisk for the whole build process | 09:09 |
| qschulz | ThomasD13: shared sstate-cache, shared DLDIR, more CPU, more RAM, hashequiv server set correctly, etc.. | 09:09 |
| ThomasD13 | I have 12 cores which run 24 threads. I thought maybe I could reduce the "bottleneck" of m2-ssd access? | 09:09 |
| ThomasD13 | I've got 72GB of RAM | 09:10 |
| JosefHolzmayrThe | ThomasD13: unless you are trying really hard to avoid it, linux effectively caches everything in ram | 09:10 |
| kanavin | ThomasD13, 12 cores is too little :-/ | 09:11 |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has joined #yocto | 09:11 | |
| kanavin | you won't nearly saturate the disk I/O with it | 09:11 |
| ThomasD13 | kanavin, its the fastest desktop CPU atm :( | 09:11 |
| JosefHolzmayrThe | ThomasD13: i've tried backing DL/SSTATE on hd vs. ssd vs. tmpfs, and there was no statistically significant difference, given the assumption that the box has enough RAM to cache stuff | 09:11 |
| kanavin | ThomasD13, what CPU do you have? | 09:11 |
| ThomasD13 | alright josef, thats sound promising | 09:12 |
| ThomasD13 | Ryzen 5900X | 09:12 |
| JosefHolzmayrThe | kanavin: and on the other hand, many builds will effectively max out at ~32 cores for parallelization limits. | 09:12 |
| kanavin | JosefHolzmayrThe, not if you're building several recipes at once | 09:13 |
| kanavin | JosefHolzmayrThe, but yes, beyond 32 cores the returns start to diminish | 09:13 |
| JosefHolzmayrThe | yeah but if you're tagetting images instead of recipes, the DAG will limit you | 09:13 |
| kanavin | ThomasD13, there's a 16 core version of that | 09:14 |
| ThomasD13 | btw, with which hardware do you work with yocto? | 09:14 |
| kanavin | ThomasD13, and really, you should get a threadripper | 09:14 |
| kanavin | JosefHolzmayrThe, yes, so optimizing the graph and reducing the critical path is perhaps the best way to speed up builds | 09:15 |
| ThomasD13 | ah, you mean 5950X. I thought the higher frq would serve better in that case | 09:15 |
| kanavin | ThomasD13, no, extra cores always win | 09:15 |
| ThomasD13 | hmmm damn it. now its to late :D | 09:15 |
| kanavin | sell :) | 09:16 |
| kanavin | and get a TR | 09:16 |
| kanavin | or wait until zen 3 based TRs are available | 09:17 |
| qschulz | might also make sense to move to server-grade CPUs if you're in a company | 09:17 |
| ThomasD13 | So you guys work with TR CPUs? | 09:18 |
| JosefHolzmayrThe | in the end it all depends on what you want to archieve | 09:18 |
| BuZZ-T | i got an x5900 - 64GB ram and an m2 ssd (pcie4.0) and i'm pretty happy with it :) but i didn't need to rebuild everything from scratch :) | 09:18 |
| ThomasD13 | Yeah probably... but at least its now roughly 4times faster than before | 09:18 |
| qschulz | but cached/proxied DLDIR company wide and a mirrored SSTATE_CACHE (SSTATE_MIRROR) and/or nfs sstate-cache is usually a very good start (+ hashequiv server) | 09:19 |
| ThomasD13 | hashequiv server is new to me - I'll google for that | 09:19 |
| JosefHolzmayrThe | our box here is a dual epyc-7-something with 256 threads, 512GB ram and 7something TB pci-nvmes | 09:19 |
| kanavin | yes, but it won't help when doing custom builds when a change you want to make is early in the task dependency graph | 09:19 |
| qschulz | I build on a Mac Mini because I like pain | 09:19 |
| ThomasD13 | :D | 09:20 |
| JosefHolzmayrThe | the real killer feature is that we can now have multiple devs kicking off builds at reasonable core counts (16-32) without competing for resources. | 09:20 |
| qschulz | My previous company was running icecc (icecream) comapny wide | 09:21 |
| kanavin | I think the main advantage of server grade CPUs is that you can put a lot of RAM in them. threadrippers are capped at 256G. | 09:21 |
| qschulz | it didn't always work properly because of outdated icecc in some devs PCs | 09:21 |
| ThomasD13 | Yeah, that server grad CPUs have a lot of PCIe lanes - thats a big advantage | 09:21 |
| JosefHolzmayrThe | in the end it all depends on the use case and the budget, how you put it to best use. | 09:21 |
| kanavin | but they cost dearly. If you want a machine just for yourself, don't get that :) | 09:21 |
| kanavin | threadrippers is the best thing that could happen to yocto | 09:22 |
| kanavin | crazy core counts available for non-astronomical price | 09:22 |
| ThomasD13 | kanavin, exactly that is true in my case. My boss doesnt really understand WHAT i am actually doing | 09:22 |
| JosefHolzmayrThe | at the moment i'm rather banging my head against some pecularities of using a container on said machine for gitlab-runner | 09:24 |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:3d2d:619e:f90d:490c> has joined #yocto | 09:28 | |
| *** m4ho <m4ho!~m4ho@81.20.119.6> has quit IRC (Read error: Connection reset by peer) | 09:32 | |
| *** BuZZ-T <BuZZ-T!~basti@213.188.127.94> has quit IRC (Remote host closed the connection) | 09:36 | |
| *** m4ho <m4ho!~m4ho@81.20.119.6> has joined #yocto | 09:49 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 10:00 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 265 seconds) | 10:02 | |
| *** camus1 is now known as camus | 10:02 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 10:02 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 10:02 | |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has quit IRC (Ping timeout: 252 seconds) | 10:10 | |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has joined #yocto | 10:28 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 10:47 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 10:47 | |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has quit IRC (Ping timeout: 252 seconds) | 10:49 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 10:52 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection) | 10:52 | |
| *** camus1 is now known as camus | 10:52 | |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has joined #yocto | 10:55 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 11:02 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 11:03 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 11:07 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 265 seconds) | 11:10 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 11:10 | |
| *** camus1 is now known as camus | 11:12 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 252 seconds) | 11:12 | |
| Ad0 | how do I make sure I have everything needed to make bluetooth serial work ? | 11:33 |
| Ad0 | it's rpi3 | 11:34 |
| Ad0 | there's always a mix between DISTRO_FEATURES and IMAGE_INSTALL on those | 11:37 |
| *** GillesM <GillesM!~gilles@89.55.119.78.rev.sfr.net> has joined #yocto | 11:38 | |
| *** tre <tre!~tre@ip5f588630.dynamic.kabel-deutschland.de> has quit IRC (Remote host closed the connection) | 11:43 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 245 seconds) | 11:50 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 11:50 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 11:56 | |
| RP | kanavin: I think you fixed a determinism issue with the parallelism option for zstd creeping into the output? Does that issue affect the current xz too? | 11:57 |
| *** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has quit IRC (Read error: Connection reset by peer) | 11:59 | |
| *** FredO3 <FredO3!~willy562@bras-base-crnypq0201w-grc-08-216-209-60-169.dsl.bell.ca> has joined #yocto | 12:00 | |
| *** ecdhe <ecdhe!~ecdhe@mms-rf-support.com> has joined #yocto | 12:00 | |
| kanavin | RP: I am lacking context; i have not seen any determinism issues with zstd. The rpm package output is the same regardless of amount of threads or compression level, | 12:02 |
| *** FredO2 <FredO2!~willy562@bras-base-crnypq0201w-grc-08-216-209-60-169.dsl.bell.ca> has quit IRC (Ping timeout: 265 seconds) | 12:03 | |
| kanavin | or, is it specific to rpm? | 12:03 |
| kanavin | is it ths http://git.yoctoproject.org/cgit.cgi/poky-contrib/diff/meta/recipes-devtools/rpm/files/0001-build-pack.c-do-not-insert-payloadflags-into-.rpm-me.patch?h=akanavin/package-version-updates&id=9c7256a3077fa1a71cdaab5942e50053e2f6992c ? | 12:04 |
| kanavin | in that case yes, it is not specific to compressor setting | 12:05 |
| RP | kanavin: Yes, that is the patch I was thinking of. I think we need this in master to fix problems I'm seeing | 12:06 |
| *** mbrothers <mbrothers!~martin@217-123-111-171.cable.dynamic.v4.ziggo.nl> has joined #yocto | 12:06 | |
| RP | kanavin: I'm trying to allow reuse of the autobuilder sstate feeds but this is breaking things | 12:06 |
| kanavin | RP: yes, I think it coincidentally worked because AB was setting threads to 8 across hosts | 12:06 |
| RP | kanavin: right, we've got lucky in a few cases :/ | 12:07 |
| RP | kanavin: fancy sending it for master? :) | 12:07 |
| kanavin | RP: meanwhile I am tackling a bigger rust fish: mozjs! :) | 12:07 |
| RP | kanavin: you do seem to enjoy 'fun' challenges ;-) | 12:07 |
| kanavin | RP: I am starting to seriously consider dropping all custom targets we create and (try to) use for rust, and use upstream ones only. | 12:07 |
| kanavin | RP: there's too much in the ecosystem that assumes use of standard targets | 12:08 |
| RP | kanavin: which custom targets do we create and why? I'm afraid I'm lacking context :/ | 12:08 |
| RP | rburton: I think rpm is one part of the sstate reuse issue we're seeing | 12:08 |
| RP | sadly there are more | 12:09 |
| RP | kanavin: we should also probably tweak the reproducibility test to change the number of threads | 12:09 |
| RP | (add or remove one in the second run) | 12:09 |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 12:10 | |
| kanavin | RP: https://doc.rust-lang.org/nightly/rustc/platform-support.html | 12:10 |
| kanavin | RP: these are the standard ones that come out of the box with rust, and are tested upstream | 12:11 |
| RP | kanavin: ah. So you're proposing we drop mips, musl, powerpc? | 12:12 |
| RP | kanavin: this would mean we drop sato since that depends on rsvg? | 12:12 |
| kanavin | RP: we on the other hand define and use custom ones (the definition is a json file), e.g. 'aarch64-poky-linux'. This is problematic, as 'the ecosystem' generally isn't expecting such custom targets, and sees them only as a way to 'bringup' new hardware. | 12:12 |
| RP | kanavin: ah, I wasn't looking far enough, there is tier 3 | 12:13 |
| kanavin | RP: not at all. standard targets do include mips, musl and powerpc. They're not guaranteed to be as well tested as 'tier 1'. | 12:13 |
| *** GillesM <GillesM!~gilles@89.55.119.78.rev.sfr.net> has quit IRC (Quit: Leaving) | 12:13 | |
| RP | kanavin: mapping our values to the rust preferred name does seem sensible | 12:13 |
| RP | we already do something like that in openssl iirc | 12:14 |
| RP | kanavin: I'll port that patch if you are busy btw, one way or another I'm going to need it to get any further fixing this sstate reuse issue | 12:15 |
| kanavin | RP: this is where the custom stuff is defined and written out: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/rust/rust-common.inc?h=master-next#n121 | 12:15 |
| kanavin | I have already had to add x32 in there (a copy-tweak from rust source code), and this got me thinking that it's problematic. | 12:16 |
| kanavin | Now that I've tried to build mozjs, it's even more problematic. | 12:16 |
| RP | kanavin: it does less than ideal so I'm open to trying changes | 12:16 |
| kanavin | RP: yes please (the rpm patch) | 12:17 |
| RP | kanavin: it seems to apply without changes :) | 12:19 |
| RP | That means something else will go badly wrong in a minute | 12:20 |
| kanavin | RP: the reason I got into mozjs upgrade is that existing mozjs (which does not use rust) won't build with python 3.10 | 12:22 |
| RP | kanavin: ah. Good timing with rust then... | 12:22 |
| jaskij[m] | where do I submit about wrong mailing list link in the layer index? specifically for meta-freescale | 12:24 |
| qschulz | jaskij[m]: to the correct ML :) | 12:30 |
| agherzan | I have some layers in the layers index that I'm not maintaining anymore (old workplaces). How can I remove myself as maintainer? | 12:30 |
| qschulz | meta-freescale@lists.yoctoproject.org | 12:30 |
| jaskij[m] | of course :D | 12:30 |
| mbrothers | Question about using patches. I have created a patch using `git format-patch -1` and applying it using `SRC_URI += "file://0001-...patch"`. But, I am getting errors while it is applied. How can I debug this easily? Which commands are used by yocto under the hood? | 12:30 |
| rburton | what errors? | 12:31 |
| rburton | that's typically right, problems may be because you didn't generate the patch from the right path, or your S is set such that the prefix is wrong | 12:31 |
| agherzan | Layer index: how can I query for all the layers I've submitted and for those that I'm a maintainer for? | 12:31 |
| jaskij[m] | qschulz: I think it's more of a global issue, caused by a change in the structure of software at lists.yoctoproject.org | 12:31 |
| jaskij[m] | even the link for Poky itself points to https://lists.yoctoproject.org/listinfo/poky where the correct link is https://lists.yoctoproject.org/g/poky | 12:32 |
| jaskij[m] | the same is true for meta-freescale | 12:33 |
| jaskij[m] | *for meta-poky | 12:33 |
| qschulz | jaskij[m]: please send patches :) | 12:34 |
| qschulz | but yes, the tool used to manage mailing list was changed about a year or two ago | 12:34 |
| jaskij[m] | where? "about this site" on layer index throws a 404 | 12:34 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 12:35 | |
| qschulz | jaskij[m]: the mail address is listed in the link you gave us above (the one for poky) | 12:35 |
| qschulz | and you have the same for other layers | 12:36 |
| jaskij[m] | So I'd have to dig through the whole index and submit about the change? Man, I need to write a crawler for that :P | 12:36 |
| qschulz | I don't know what the layer index "about this site" page should redirect to sorry | 12:37 |
| qschulz | halstead: michaelo: ndec_: maybe know ^ | 12:37 |
| qschulz | jaskij[m]: only the layers hosted on git.yoctoproject.org and git.openembedded.org | 12:38 |
| qschulz | it's better to have a patch for a few than for none, so at least send the ones you encounter, though we would be very grateful if you did it for all repos since you're offering :) | 12:39 |
| *** sstiller <sstiller!~sstiller@p200300f07f115500853799e88de78366.dip0.t-ipconnect.de> has joined #yocto | 12:39 | |
| ndec_ | qschulz: jaskij[m] : right, i can see the issue.. i can fix the index for meta-freescale.. but I am not sure if we can do a fix-all-at-once change.. | 12:40 |
| qschulz | ndec_: I pinged you more about https://layers.openembedded.org/layerindex/about/ :) | 12:40 |
| jaskij[m] | Might as well write an automated scanner for dead mailing list links and such. Been looking for a project to learn Rust :P although with my life as it is, no promises on timelines. | 12:41 |
| qschulz | aaaaaaah, jaskij[m] you were talking about the mailing list displayed on the layersindex? I thought in some layers' README or something | 12:41 |
| ndec_ | i am not sure it is a patch that we need. i think we need to make a change in the layerindex admin panel. | 12:41 |
| jaskij[m] | layerindex, yes | 12:42 |
| jaskij[m] | my bad if I caused confusion | 12:42 |
| *** argonautx <argonautx!~argonautx@i5E8673D8.versanet.de> has joined #yocto | 12:42 | |
| mbrothers | rburton: I am getting "Cannot rename file without two valid file names" where if I do it locally (git am 0001...patch) it works fine | 12:42 |
| qschulz | jaskij[m]: then I don't know where this needs to be changed, ndec_ and others will know :) | 12:42 |
| ndec_ | the README in meta-freescale is showing the right mailing list. but layerindex does not parse the mailing list from the tree. it must have been entered manually | 12:42 |
| rburton | mbrothers: it usually applies using quilt | 12:43 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 12:43 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 12:43 | |
| mbrothers | alright, I'll try to reproduce it using quilt, I'll get back to you! | 12:43 |
| rburton | you can set PATCHTOOL=git if you want, but it sounds like your patch is just a bit weird and might need a bit of love to not be a git-specific patch | 12:43 |
| mbrothers | Thanks! | 12:43 |
| ndec_ | jaskij[m]: i am sure a BZ entry with the list of issues you found would be helpful | 12:43 |
| mbrothers | rburton: Yes, it is renaming+modifying sources, so it may have some attention there | 12:44 |
| mbrothers | rburton: just for my information, is it possible to add that PATCHTOOL directive also in the "SRC_URI += file://...patch" line? | 12:45 |
| rburton | no, just set PATCHTOOL in the recipe | 12:45 |
| mbrothers | rburton: alright, thanks! | 12:45 |
| jaskij[m] | ndec_: I'll do it once I'm home, probably will try to get started on that scanner too | 12:46 |
| ndec_ | it's a property (mailing list) in the layer entry. i am not sure if the layer maintainer has permission to update the information directly, or if it should be an admin. maybe bluelightning or RP would know. in any case, it's a good finding.. | 12:48 |
| ndec_ | qschulz: re: the about page which is broken, please submit a bug :) | 12:48 |
| jaskij[m] | ndec_: I've got a bunch of questions, is there some docs for the layer index I could read, or a repo I could try going through? | 12:50 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 12:51 | |
| RP | ndec_: I do not know. I think rburton did get admin access | 12:51 |
| rburton | the layer owner can update it | 12:51 |
| rburton | what layer? | 12:52 |
| ndec_ | i have admin access too, i can make the change. but i wanted to understand if admins should make the changes, or if we should request all maintainers to verify their entry. | 12:52 |
| ndec_ | meta-freescale mailing in the layerindex points to the old mailman, not groups.io link. | 12:52 |
| ndec_ | and probably many others. | 12:52 |
| ndec_ | ah, rburton you answered my question :) | 12:53 |
| rburton | so the owner of meta-freescale is otavio | 12:53 |
| ndec_ | hmm. actually the problem might be slightly different.. https://lists.yoctoproject.org/listinfo/meta-freescale is (I think) supposed to redirect to the new groups.io link, but it does not. while similar links for OE work. | 12:55 |
| ndec_ | e.g. http://lists.openembedded.org/mailman/listinfo/openembedded-core redirects fine. | 12:55 |
| rburton | ndec_: yeah definitely two problems | 12:56 |
| rburton | i've updated the layer for otavio | 12:56 |
| rburton | but halstead should setup that redirect | 12:56 |
| ndec_ | i am pretty sure it was there initially, but it is broken now.. | 12:56 |
| yates | if i have several patches in a recipe (several SRC_URI += "file://patch1.patch", SRC_URI += "file://patch2.patch", ...) what order will they be applied in? alphabetical? | 13:02 |
| qschulz | yates: order in which they are appearing in SRC_URI | 13:03 |
| yates | qschulz: +1 | 13:03 |
| *** davidinux <davidinux!~davidinux@84.17.59.156> has quit IRC (Ping timeout: 245 seconds) | 13:07 | |
| *** davidinux <davidinux!~davidinux@net-2-34-77-16.cust.vodafonedsl.it> has joined #yocto | 13:09 | |
| *** Nate[m]1 <Nate[m]1!~nsdrudema@2001:470:69fc:105::f855> has quit IRC (Ping timeout: 250 seconds) | 13:09 | |
| agherzan | bluelightning: Hi Paul. I have a set of layers in the layer index that I'd like to remove myself as maintainer (past work). And also, I have submitted a layer with my current work email which will create the same issue in the future. I can't make these changes as the emails differ from my current one - some of them I don't even have access to anymore. | 13:10 |
| *** Jari[m] <Jari[m]!~jarihmatr@2001:470:69fc:105::6a7> has quit IRC (Ping timeout: 268 seconds) | 13:11 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has quit IRC (Ping timeout: 268 seconds) | 13:11 | |
| agherzan | And I think the way lindex does it, is by matching the maintainer's email to the account's email. | 13:11 |
| *** davidinux <davidinux!~davidinux@net-2-34-77-16.cust.vodafonedsl.it> has quit IRC (Ping timeout: 245 seconds) | 13:15 | |
| *** davidinux <davidinux!~davidinux@84.17.59.156> has joined #yocto | 13:17 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 13:17 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 265 seconds) | 13:31 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 13:33 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 13:33 | |
| *** davidinux <davidinux!~davidinux@84.17.59.156> has quit IRC (Ping timeout: 252 seconds) | 13:41 | |
| *** davidinux <davidinux!~davidinux@84.17.59.156> has joined #yocto | 13:43 | |
| *** kiran_ <kiran_!~kiran@2607:fea8:5a80:ea0:fc4f:e2bc:76ca:ef97> has joined #yocto | 13:49 | |
| *** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 13:53 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 13:56 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:58 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 13:58 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 14:01 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 14:02 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 14:04 | |
| jonesv[m] | Can somebody help me understand the syntax here? https://github.com/openembedded/meta-openembedded/blob/master/meta-networking/recipes-protocols/quagga/quagga.inc#L196-L199... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/1280bcbd875d7ea7fc29303008493aaf0550eace) | 14:06 |
| qschulz | jonesv[m]: it's the marker for an override | 14:09 |
| *** Nate[m]1 <Nate[m]1!~nsdrudema@2001:470:69fc:105::f855> has joined #yocto | 14:09 | |
| *** arca1 <arca1!~arca@208.116.134.46> has joined #yocto | 14:09 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has joined #yocto | 14:09 | |
| *** Jari[m] <Jari[m]!~jarihmatr@2001:470:69fc:105::6a7> has joined #yocto | 14:09 | |
| qschulz | jonesv[m]: https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-syntax-overrides | 14:10 |
| qschulz | it is the new syntax, previously (all current releases except master) it was an underscore | 14:11 |
| *** arca1 is now known as artri | 14:11 | |
| *** mihai <mihai!~mihai@user/mihai> has joined #yocto | 14:14 | |
| jonesv[m] | oh, right. But then that brings me to a new question: I am using the following, but it does not start the two services automatically:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/15f6f483ef2fee5f85cf64105b69918fc6be7f3a) | 14:17 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Quit: camus) | 14:17 | |
| *** lucaceresoli <lucaceresoli!~ceresoli@tech.aim-sportline.com> has quit IRC (Quit: Leaving) | 14:18 | |
| jonesv[m] | I am just trying to define two services from one recipe. Those two binaries `gpio-shutdown` and `i2c-battery` are both built by this recipe, and installed properly. I can `service gpio-shutdown start` and `service i2c-battery start` manually, but they don't start automatically | 14:19 |
| jonesv[m] | I have been looking at `./meta/classes/update-rc.d.bbclass` for two hours now, and I don't really get how the "multi-package" way works (if it does at all). Happy to get advice there | 14:19 |
| jonesv[m] | Also I don't get what they mean with "package", because for me a recipe describes one package. So I actually define multiple services here, not multiple packages 🤔 | 14:20 |
| qschulz | jonesv[m]: a recipe builds multiple packages | 14:24 |
| qschulz | (in the immense majority of cases) | 14:24 |
| qschulz | it just happens that ${PN} is both the name of the recipe and of the "main" package | 14:24 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 14:24 | |
| jonesv[m] | oh, I see. So it sounds like I should define those packages in my first multi-packages recipe | 14:25 |
| qschulz | jonesv[m]: which Yocto release are you working on currently? | 14:26 |
| jonesv[m] | qschulz: 3.2.1 | 14:27 |
| jonesv[m] | Seems like the quagga recipe defines the multiple packages here: https://github.com/openembedded/meta-openembedded/blob/master/meta-networking/recipes-protocols/quagga/quagga.inc#L157-L172 | 14:29 |
| jonesv[m] | Trying to find in the docs how to build multiple packages from one recipe, it seems like I missed that 😁 | 14:30 |
| qschulz | jonesv[m]: I think the entries in INITSCRIPT_PACKAGES should be present in PACKAGES too and the init script that is enabled via an INISCRIPT_PACKAGE override should be in the package | 14:30 |
| qschulz | don't know how to convey my thoughts better than this | 14:30 |
| jonesv[m] | But that's all done in the same recipe, right? I just need to understand how to deal with multiple packages in one recipe I think | 14:30 |
| qschulz | basically, you need FILES_gpio-shutdown += "/path/to/gpio-shutdown.service" and PACKAGES =+ "gpio-shutdown" | 14:31 |
| qschulz | +- the typos and correct paths | 14:31 |
| qschulz | you can check if your initscript makes it to the correct package by running oe-pkgdata-util find-path '*gpio-shutdown*' | 14:31 |
| jonesv[m] | Got it, let me try that | 14:32 |
| jonesv[m] | Just for the record, this is my simple recipe right now: https://pastebin.com/TbNr5S5V | 14:32 |
| *** Sion <Sion!~dev@D584BE1E.static.ziggozakelijk.nl> has quit IRC (Ping timeout: 250 seconds) | 14:32 | |
| qschulz | jonesv[m]: your cmake should install the files in the correct directories already so you don't need a do_install_append | 14:33 |
| qschulz | but that's nitpicking | 14:33 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 14:33 | |
| qschulz | but yeah, missing the PACKAGES and FILES variable for each new package | 14:34 |
| jaskij[m] | why would `dnf repoquery` on the device give me empty results? any tips on where to look? | 14:34 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 14:34 | |
| jaskij[m] | in particular `dnf repoquery --list glibc-utils` is empty | 14:34 |
| jonesv[m] | qschulz: but those do_install_append are for the sysvinit services, so they are not part of the project itself (only the recipe). Is that bad practice? | 14:35 |
| *** ThomasD13 <ThomasD13!~thomasd13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC (Ping timeout: 246 seconds) | 14:35 | |
| qschulz | jonesv[m]: misread the recipe, this way is fine, though probably they could be in the git repo already? but that's up to the maintainer's taste | 14:35 |
| jonesv[m] | got it | 14:35 |
| qschulz | jaskij[m]: don't know much about dnf repoquery, but, do youa ctually have a dnf repo somewhere to query? | 14:36 |
| jaskij[m] | yup, all set up | 14:36 |
| *** artri <artri!~arca@208.116.134.46> has left #yocto (Leaving) | 14:37 | |
| *** artri <artri!~arca@208.116.134.46> has joined #yocto | 14:38 | |
| *** camus <camus!~Instantbi@2409:8a1e:9118:4360:8077:fc82:8ca9:a945> has joined #yocto | 14:44 | |
| jonesv[m] | qschulz: that `oe-pkgdata-util` is super cool! I have been looking for a way to list all my packages like I saw once in a debug output, e.g.:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/6f6ce0758817df9d6ec863a6412e82abb43039df) | 14:46 |
| jaskij[m] | So, I've found out that postgresql's `initdb` actually depends on `locale` to find out existing locales. Adding an RRECOMNDS is probably something for the mailing list? | 14:47 |
| jaskij[m] | without `locale`, you get a warning: `UTC [4118] WARNING: no usable system locales were found` | 14:48 |
| RP | jaskij[m]: I'd make that a RDEPENDS but yes, please send a patch | 14:50 |
| jaskij[m] | true, working with locale is such a basic thing for a database that `RDEPENDS` is probably better | 14:51 |
| *** rber|res <rber|res!~rber|res@ppp-2-86-135-193.home.otenet.gr> has quit IRC (Read error: Connection reset by peer) | 14:51 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 14:51 | |
| fray | just remember many people are building systems without locales, so if the component won't work in that it would be nice to identify and disable that recipe in some way.. | 14:52 |
| jaskij[m] | this also probably needs safeguarding for whether glibc is used | 14:52 |
| RP | jaskij[m]: there is a libc-glibc override | 14:53 |
| jaskij[m] | fray: how do I detect that? by checking whether `GLIBC_GENERATE_LOCALES` is empty? | 14:53 |
| qschulz | jonesv[m]: enabling buildhistory feature should give you what you want | 14:53 |
| *** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto | 14:56 | |
| fray | I assume this needs to work in musl as well.. so I'm not sure.. | 14:58 |
| jaskij[m] | fray: for now I'm sending this as a glibc-only patch, I've never worked with musl | 14:59 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 14:59 | |
| jaskij[m] | hoping someone will respond with a necessary correction for musl if it's available | 14:59 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 15:00 | |
| fray | Ya, IMAGE_LINGUAS, but that shouldn't be used as it's "image" specific. I thought there was a variable that said 'construct these locals'. That is the one I was thinking of, but I'm not seeing it | 15:00 |
| jaskij[m] | for glibc it's GLIBC_GENERATE_LOCALES, but looking at the recipe an empty string is understood as "all": http://cgit.openembedded.org/openembedded-core/tree/meta/classes/libc-package.bbclass?h=dunfell#n199 | 15:02 |
| fray | Ya, it's GLIBC_GENERATE_LOCALES .. 'all' is fine, other things might be.. and blank is probably "won't work" | 15:02 |
| jaskij[m] | blank is equal to 'all', as per the source linked | 15:02 |
| fray | Hmm.. I thought there was a way to say none.. | 15:02 |
| fray | Maybe " " | 15:02 |
| fray | maybe I'm remembering wrong and locales are always generated "in some way".. then IMAGE_LINGUAS is what gets installed or not | 15:04 |
| jaskij[m] | I think having glibc without locale support is not really supported. Sure, you may have those locales not installed (as is common), but glibc will have locale support either way | 15:04 |
| *** sstiller <sstiller!~sstiller@p200300f07f115500853799e88de78366.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving) | 15:04 | |
| fray | Ya ya.. glibc locale APIs will always be present for sure | 15:04 |
| fray | it's been a very long time since we could just turn off locales at that level.. | 15:04 |
| jaskij[m] | so just `RDEPENDS` on `glibc-utils`, *if* `TCLIBC` is `glibc` | 15:05 |
| jaskij[m] | is what I'm thinking | 15:05 |
| qschulz | jaskij[m]: I think there's a glibc OVERRIDES available, so an RDEPENDS:${PN}:append:glibc should probably be fine? | 15:06 |
| fray | ya.. that should work fine (and be simpler) | 15:08 |
| fray | originally I was thinking we could disable packaging of any locale stuff, but I don't see that -- so my memory was wrong | 15:08 |
| jaskij[m] | If there's such an override it'll be perfect | 15:09 |
| qschulz | jaskij[m]: :libc-glibc | 15:10 |
| jaskij[m] | How much testing is required for patches to be submitted? | 15:11 |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-07-184-145-217-104.dsl.bell.ca> has joined #yocto | 15:11 | |
| jaskij[m] | Locally I'm working with pgsql 13.3 backported from Hardknott to Dunfell | 15:12 |
| jaskij[m] | Thanks qschulz | 15:14 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 15:14 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 15:14 | |
| *** oobitots <oobitots!~oobitots@aer01-mda1-dmz-wsa-2.cisco.com> has quit IRC (Quit: Client closed) | 15:16 | |
| *** thekappe <thekappe!~user@198.90.66.177> has quit IRC (Quit: WeeChat 1.9.1) | 15:37 | |
| *** oobitots <oobitots!~oobitots@aer01-mda1-dmz-wsa-2.cisco.com> has joined #yocto | 15:37 | |
| *** pgowda <pgowda!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 15:39 | |
| *** fbre <fbre!~fbre@145.253.222.69> has quit IRC (Quit: Client closed) | 15:47 | |
| *** dev1990 <dev1990!~dev@78.10.71.240> has joined #yocto | 15:47 | |
| jonesv[m] | qschulz: does not seem to work either :(. Does this look good at least? https://pastebin.com/2VLrezM5 | 15:47 |
| jonesv[m] | I think I misunderstand how to use FILES here: https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#var-FILES. Sounds like I should not use the `${WORKDIR}`, but if I use the target path here, how does it know which file should go there? | 15:50 |
| qschulz | jonesv[m]: for sure not, it should be ${sysconfdir}/init.d/ | 15:52 |
| qschulz | check with oe-pkgdata-util list-pkg-files gpio-shutdown does not have the file | 15:52 |
| qschulz | it is very likely that you also shoul dhave PACKAGES =+ and not PACKAGES += | 15:53 |
| jonesv[m] | oh, I thought `=+` was a typo 😅 | 15:54 |
| qschulz | and ${INIT_D_DIR} could probably replace ${sysconfdir}/init.d/ not that it matters much :) | 15:54 |
| *** mbrothers <mbrothers!~martin@217-123-111-171.cable.dynamic.v4.ziggo.nl> has quit IRC (Ping timeout: 250 seconds) | 15:54 | |
| qschulz | jonesv[m]: a file can only appear in one package, so the first FILES to have a regex matching the file gets it | 15:55 |
| jonesv[m] | qschulz: so `FILES_gpio-shutdown += "${D}${sysconfdir}/init.d/gpio-shutdown.sh"`? You don't have the `${D}` above | 15:55 |
| qschulz | and the PACKAGES variable is read left to right | 15:55 |
| qschulz | jonesv[m]: no, I didn't write ${D} | 15:55 |
| jonesv[m] | So for the install_append, I need `${D}`, but for the `FILES`, I don't? | 15:55 |
| qschulz | yes, because FILES mechanism looks into ${D} for files | 15:56 |
| jonesv[m] | right, let my write that down | 15:56 |
| qschulz | ${D} being a temporary rootfs skeleton per recipe | 15:56 |
| rburton | fray: around? | 15:59 |
| *** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 15:59 | |
| fray | ya.. on an internal meeting so I might be a bit slow responding, but I'm here | 16:02 |
| *** oobitots <oobitots!~oobitots@aer01-mda1-dmz-wsa-2.cisco.com> has quit IRC (Quit: Client closed) | 16:04 | |
| rburton | fray: having fun with gitsm fetcher. can i still blame you for that? | 16:04 |
| *** oobitots <oobitots!~oobitots@aer01-mda1-dmz-wsa-2.cisco.com> has joined #yocto | 16:04 | |
| *** mbrother1 <mbrother1!~martin@188.201.252.82> has joined #yocto | 16:04 | |
| fray | lol what isn't working for you.. I can at least tell you if I know about it... :) | 16:05 |
| mbrother1 | rburton: turns out I had binary files in my patch which are a problem in quilt when not using the `--binary` flag when creating the patch | 16:05 |
| fray | (the one thing that people have complained about and I've so far not done anything about -- is login required for sub modules) | 16:05 |
| rburton | fray: so say v1 of a gitsm repo has foo as a submodule. update to v2 changes foo to bar. on build, it doesn't go and get bar. | 16:06 |
| fray | Ohhh it should | 16:06 |
| fray | I thought there was a test case in place for that specific condition (bitbake test case) | 16:06 |
| fray | I know early on there was a bug that it wasn't doing that reload recursively.. but that was fixed.. | 16:07 |
| rburton | i've a reproducer, two releases of edk2-firmware where cmocka changes repo | 16:07 |
| rburton | i'll see if the test case is similar or i can replicate in the same way | 16:07 |
| fray | What is changing from v1 to v2? URL only, path, and/or submodule entry name? | 16:07 |
| rburton | yeah was just wondering if the tracking code looks at just the path | 16:07 |
| RP | rburton: writing a selftest would be a great thing anyway as we can then stop things regressing | 16:07 |
| fray | ya, if you can either replicate it with the existing test case, or get me a test case I can look fairly quickly.. not sure I can't fix it this week -- but it SHOULD work | 16:08 |
| rburton | right | 16:08 |
| *** nateglims <nateglims!~nateglims@52.95.4.12> has joined #yocto | 16:08 | |
| rburton | fray: https://github.com/tianocore/edk2/commit/2ad22420a710dc07e3b644f91a5b55c09c39ecf3 just the url changed | 16:08 |
| fray | rburton the tricky part with this is if you just 'scan things' you get race conditions (we had a LOT of them early in the development of the code). Moving everything to recursive with locking fixed that, but it's possible that we're not looking at the right set of values as we recurse | 16:08 |
| rburton | right, as the path is the same but the tarball it expands in unpack is different | 16:09 |
| fray | Ya, it may be looking at JUST the path, but it was intended to look for both | 16:09 |
| rburton | also of course this code is horrid :) | 16:09 |
| fray | yes it is | 16:09 |
| fray | it is _WAY WAY WAY WAY_ better then where I started.. | 16:09 |
| rburton | i think its time for fetch3 ;) | 16:10 |
| fray | but trying to replicate git submodule (and it's quarks) without running git submodule.. yikes | 16:10 |
| fray | code does: | 16:12 |
| fray | gitmodules = runfetchcmd("%s show %s:.gitmodules" % (ud.basecmd, ud.revisions[name]), d, quiet=True, workdir=workdir) | 16:12 |
| fray | then parses the response and uses the key of path and the value is the url (I think) | 16:13 |
| fray | iterates over each of those and verifies everything is filled out. If it is it then stores the paths, revisions, uris and any subrevisions (don't remember what this means) | 16:13 |
| fray | then for each module it processes based on the submodule entry name.... | 16:14 |
| fray | builds up a URL table and calls itself (recursively) for the submodules.. | 16:14 |
| fray | (thats more or less how it fetches).. so that seems fairly straight forward | 16:14 |
| fray | It's probably 'need_update' where things fall apart.. | 16:14 |
| fray | Does the main SRC_URL change? no we end, otherwise we have to process the submodules.. | 16:15 |
| rburton | no just the srcrev | 16:15 |
| rburton | which includes a change to .gitmodules which changes the url of a submodule | 16:16 |
| fray | sorry I mean main SRCREV | 16:16 |
| rburton | yes | 16:16 |
| jonesv[m] | qschulz: I'm really about to cry 😅, I think I must be stupid. So this should be right?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/96ffb36d486c17478beef2f2c8c265b9dcf80118) | 16:16 |
| fray | the idea is if the main one didn't change, then we don't need to do further evaluation as submoudles can't change by definition.. (the same happens when we recursively scan) | 16:16 |
| rburton | WOOP WOOP yocto shoutout by nasa | 16:17 |
| fray | rburton: the URL changed, but did the SRCREV change? | 16:17 |
| rburton | fray: so the recipe changes the SRCREV of the main recipe. that change includes a change to .gitmodules which changes the url of a submodule. | 16:18 |
| fray | ya, but does it change the SRCREV of the submodule? | 16:18 |
| rburton | gotcha | 16:18 |
| fray | There _IS_ a check that if the SRCREV of the submodule is unchanged, it skips further checking | 16:18 |
| rburton | no, it just switches to a different URL | 16:18 |
| fray | ok.. that is likely the issue then | 16:18 |
| fray | self.process_submodules(ud, ud.clonedir, download_submodule, d) | 16:19 |
| fray | # Drop a nugget for the srcrev we've fetched (used by need_update) | 16:19 |
| fray | runfetchcmd("%s config --add bitbake.srcrev %s" % \ | 16:19 |
| fray | (ud.basecmd, ud.revisions[ud.names[0]]), d, workdir=ud.clonedir) | 16:19 |
| fray | look at the top of need_update.. it looks for known srcrevs.. and then checks them skipping items it has already seen.. | 16:19 |
| fray | The only thing I can think of is somehow adding the URL as well.. so it'd be: | 16:19 |
| fray | bitbake.srcurl = <url> | 16:19 |
| fray | bitbake.srcrev = <srcrev> | 16:20 |
| fray | then load them both, and compare | 16:20 |
| rburton | gotcha, will try | 16:20 |
| fray | So ya, lack of SRCREV changing is your cause.. but I'm not sure the 'fix', that is just one possibility | 16:20 |
| rburton | sounds feasible | 16:20 |
| fray | Somehow we need to know the url that 'last time through', so we can quickly compare and bail.. | 16:20 |
| fray | anyway you have your reproducer now. Change the upstream URL w/o changing the SRCREV.. | 16:21 |
| *** mbrother1 <mbrother1!~martin@188.201.252.82> has quit IRC (Ping timeout: 240 seconds) | 16:25 | |
| fray | (I doubt I thought of a situation where the URL changed, but the SRCREV didn't at the same time) | 16:27 |
| barath | does anyone know if the covered/notcovered fix is being worked on for dunfell? I've tried backporting the fix from hardknott to dunfell, but we're still getting those errors | 16:30 |
| jaskij[m] | how long does it take to get an account on BZ? | 16:30 |
| jaskij[m] | and can I just send an e-mail to the mailing list with the bugs? | 16:31 |
| jaskij[m] | *bug | 16:31 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 16:34 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 16:34 | |
| *** mckoan is now known as mckoan|away | 16:39 | |
| *** zpfvo <zpfvo!~fvo@88.130.219.135> has quit IRC (Remote host closed the connection) | 16:39 | |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has quit IRC (Ping timeout: 252 seconds) | 16:45 | |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has joined #yocto | 16:46 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-07-184-145-217-104.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.3-dev) | 16:46 | |
| RP | jaskij[m]: we can ask halstead | 16:47 |
| halstead | jaskij[m]: accounts are added within an hour usually. There isn't a way to submit bugs via email. | 16:49 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:54 | |
| override | how can I make an image recipe compress only the rootfs to a format bmap likes and also generate a bmap file and a hash file for ONLY the rootfs in question. | 17:11 |
| halstead | jaskij[m], rburton, ndec_ , about the bad links and mailing lists. We added redirects from the old locations to the new ones as best as possible so old links would work. Especially direct links to message archives. | 17:13 |
| jaskij[m] | I | 17:14 |
| jaskij[m] | *I'm mostly looking to click through from layer index to actually getting the list e-mail address | 17:14 |
| jaskij[m] | which, at least for meta-intel and meta-freescale, isn't possible currently | 17:15 |
| *** nerdboy <nerdboy!~nerdboy@47.143.129.189> has joined #yocto | 17:24 | |
| *** frieder_ <frieder_!~frieder@i59F4BCD2.versanet.de> has quit IRC (Remote host closed the connection) | 17:27 | |
| argonautx | hello out there, i want to build kernel modules on the target system and I read that have to add kernel-dev to achive this | 17:33 |
| argonautx | but there is no /usr/src/kernel directory on the target fs | 17:33 |
| argonautx | what did I miss? | 17:33 |
| zeddii | install kernel-devsrc to your image | 17:36 |
| *** nateglims <nateglims!~nateglims@52.95.4.12> has quit IRC (Quit: Client closed) | 17:36 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-07-184-145-217-104.dsl.bell.ca> has joined #yocto | 17:38 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 17:39 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 17:40 | |
| *** oobitots <oobitots!~oobitots@aer01-mda1-dmz-wsa-2.cisco.com> has quit IRC (Quit: Client closed) | 17:41 | |
| *** oobitots <oobitots!~oobitots@aer01-mda1-dmz-wsa-2.cisco.com> has joined #yocto | 17:41 | |
| *** nateglims <nateglims!~nateglims@52.95.4.12> has joined #yocto | 17:42 | |
| *** kayterina <kayterina!~kayterina@chios.esd.ece.ntua.gr> has quit IRC (Quit: Leaving) | 17:42 | |
| nateglims | Is there a written grammar for bb files or is it just bitbake as a reference implementation? | 17:42 |
| override | zeddii: you know what I can add to image for it to give out rootfs in a format bmaplikes and also an accompanying bmap file??? | 17:44 |
| *** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has quit IRC (Quit: Client closed) | 17:47 | |
| *** oobitots <oobitots!~oobitots@aer01-mda1-dmz-wsa-2.cisco.com> has quit IRC (Quit: Client closed) | 17:49 | |
| *** oobitots <oobitots!~oobitots@aer01-mda2-dmz-wsa-9.cisco.com> has joined #yocto | 17:50 | |
| RP | so gnupg is different on my system compared to the autobuilder because of /usr/bin/sendmail | 17:54 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 17:57 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 17:57 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 17:59 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 18:01 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 18:03 | |
| *** oobitots <oobitots!~oobitots@aer01-mda2-dmz-wsa-9.cisco.com> has quit IRC (Ping timeout: 256 seconds) | 18:07 | |
| argonautx | zeddii: thanks | 18:11 |
| *** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto | 18:11 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 18:14 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 18:14 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 18:40 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 18:40 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 18:40 | |
| *** ant__ <ant__!~ant@host-82-54-240-7.retail.telecomitalia.it> has joined #yocto | 18:48 | |
| ndec_ | halstead: ok.. well, i think we need to update the links anyways to the new location! | 18:50 |
| halstead | ndec_: For sure. I'm not sure why the link in question does redirect now or if it ever did. | 18:50 |
| halstead | ndec_: It looks like meta-freescale layer has already updated. Maybe you did that? | 18:51 |
| ndec_ | yes, well. rburton did. | 18:51 |
| ndec_ | but given that a lot of layers need to be updated, perhaps there is a better way than doing it manually.. | 18:52 |
| *** florian <florian!~florian@dynamic-078-048-039-016.78.48.pool.telefonica.de> has joined #yocto | 18:55 | |
| smurray | RP: I can't seem to ssh into my setup at home this morning, but I grabbed some bits on my laptop and could get the ptest patch in meta-agl-core updated in a pinch | 18:56 |
| RP | smurray: thanks, these things always happen the most inconvenient way :/ | 18:58 |
| *** amitk <amitk!~amit@103.208.71.3> has quit IRC (Quit: leaving) | 19:01 | |
| smurray | RP: when are you planning on pulling the queued master-next changes into master? | 19:03 |
| RP | smurray: I was hoping for sooner than later but if you want me to wait I can I guess | 19:05 |
| smurray | RP: it's more that I'm wondering if I push an update for that if it'll break test runs before you push to master | 19:06 |
| RP | smurray: oh, I can push whenever it is ready :) | 19:06 |
| smurray | RP: ah, okay. I'll do a test build of ptest-runner with the patch here ASAP then | 19:07 |
| *** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has quit IRC (Ping timeout: 260 seconds) | 19:11 | |
| smurray | RP: tbh, I'm not sure it'll break the meta-agl-core test on the autobuilder, as I don't think AGL_FEATURES = "aglcore" is set for that | 19:11 |
| *** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has joined #yocto | 19:14 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 19:15 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 19:15 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection) | 19:15 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 19:16 | |
| *** camus <camus!~Instantbi@2409:8a1e:9118:4360:8077:fc82:8ca9:a945> has quit IRC (Quit: camus) | 19:17 | |
| *** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has quit IRC (Quit: Client closed) | 19:20 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 19:26 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 19:26 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 19:31 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 19:31 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection) | 19:31 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 19:32 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection) | 19:32 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 19:32 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection) | 19:32 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 19:32 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Remote host closed the connection) | 19:33 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 19:34 | |
| vd | I'm running out of space, is it safe to create mount points on my laptop for the DL_DIR, TOPDIR and SSTATE_DIR? | 20:03 |
| *** nateglims <nateglims!~nateglims@52.95.4.12> has quit IRC (Quit: Client closed) | 20:05 | |
| RP | vd: SSTATE_DIR and DL_DIR work fine. TOPDIR should work too but I don't do that locally so slightly less sure | 20:07 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 20:09 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 20:10 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 20:10 | |
| *** florian <florian!~florian@dynamic-078-048-039-016.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 20:17 | |
| *** nateglims <nateglims!~nateglims@52.95.4.12> has joined #yocto | 20:21 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 20:24 | |
| smurray | RP: I've pushed the patch update to meta-agl's next branch, ptest-runner should build w/o warnings if you merge the master-next updates | 20:33 |
| jaskij[m] | can I use overrides in recipe appends? particularly, I want different systemd-conf _bbappend files depending on the target machine | 20:34 |
| vd | jaskij[m] sure, SOMEVAR_append_myoverride = " othervalue" | 20:35 |
| vd | (s/_/:/g for the new syntax) | 20:35 |
| jaskij[m] | vd: not in variables, but on the filename level | 20:35 |
| jaskij[m] | sorry for badly wording it the first time | 20:36 |
| jaskij[m] | does it work like this at all in filenames? | 20:36 |
| vd | overrides aren't supported on a file basis for bbappend I think | 20:37 |
| jaskij[m] | what I feared, I'll just need to separate it differently | 20:38 |
| vd | but you can have many systemd-conf _%.bbappend files | 20:39 |
| vd | (and the VAR_append_myoverride syntax in them for sure) | 20:39 |
| jaskij[m] | vd: how, if they're all in the same directory? I have multiple machines supported in one layer, for what it's worth | 20:40 |
| jaskij[m] | rn, I'm thinking more of just making an include per machine and just include them all in `systemd-conf_%.bbappend` | 20:41 |
| vd | jaskij[m] you can place them in recipes-MACHINE1/systemd-conf/systemd-conf_%.bbappend, recipes-MACHINE2/systemd-conf/systemd-conf_%.bbappend, and so on. | 20:42 |
| vd | jaskij[m] but you would also edit the recipe variables within the machine configuration files | 20:42 |
| *** nateglims51 <nateglims51!~nateglims@52.95.4.12> has joined #yocto | 20:45 | |
| vd | but you could* | 20:45 |
| *** nateglims51 <nateglims51!~nateglims@52.95.4.12> has quit IRC (Client Quit) | 20:45 | |
| vd | as in two different options | 20:45 |
| *** nateglims <nateglims!~nateglims@52.95.4.12> has quit IRC (Ping timeout: 256 seconds) | 20:45 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 20:45 | |
| jaskij[m] | not really, I need to add in board-specific network configuration files | 20:46 |
| jaskij[m] | so that, for example, by default it boots with DHCP | 20:47 |
| RP | smurray: I merged, thanks | 20:47 |
| smurray | RP: when I get home I'll send the latest version of the patch to the ml | 20:49 |
| RP | smurray: sounds good, thanks | 20:50 |
| vd | jaskij[m] that's already the default I think, but you can just append FILESEXTRAPATHS and SRC_URI with the machines overrides in bbappend files | 20:51 |
| jaskij[m] | I could. If I didn't need multiple options per machine | 20:51 |
| jaskij[m] | Eg. for dual ethernet I need both an option for separate and bridged | 20:52 |
| jaskij[m] | and this, in turn, is chosen per image | 20:52 |
| olani[m] | jaskij: If the files are stored with the recipe you can use subpaths like recipes-X/systemd-conf/systemd-conf/MACHINE1/whatever.service and SRC_URI += "whatever.service" and let the recipe pick the appropriate file. This assumes they have the same name. | 20:56 |
| jaskij[m] | oh, I'm doing that alright, otherwise the files subdir would be a total mess | 20:57 |
| jaskij[m] | just thought someone could come up with something smarter than what I'm already doing | 20:59 |
| jaskij[m] | mostly, I just have a very visceral reaction to long files | 20:59 |
| jaskij[m] | so if my _bbappend would be 150 lines, I'm looking to split it | 20:59 |
| olani[m] | I probably don't understand exactly what you are trying to do. For one thing I do not understand how the image interacts with the machines here. | 21:03 |
| jaskij[m] | Yeah, I'd have to do a whole writeup to just explain, or mock the file structure I'm currently using. | 21:04 |
| jaskij[m] | Which... I might actually do that mock and post it on the mailing list | 21:04 |
| *** jamesp_ <jamesp_!sid520428@id-520428.tinside.irccloud.com> has joined #yocto | 21:16 | |
| *** jamesp_ is now known as jamestperk | 21:18 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 21:35 | |
| jaskij[m] | olani: to attempt a rundown, there's two machines, one of them has two ethernet ports. Now, those two ethernet ports can be separate or bridged, and if bridged the bridge can either be a DHCP client or server. So one of the machines has *three* possible network configurations, and I want to select among them when creating the image. | 21:43 |
| jaskij[m] | that's what makes this all so complicated | 21:43 |
| *** vd44 <vd44!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 21:45 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Ping timeout: 256 seconds) | 21:48 | |
| vd44 | jaskij[m] that's not complicated. In recipes-core/systemd-conf/systemd-conf_%.bbappend, add a few SRC_URI_append_MACHINE1 = " file://br0.network" etc. | 21:51 |
| *** kiran_ <kiran_!~kiran@2607:fea8:5a80:ea0:fc4f:e2bc:76ca:ef97> has quit IRC (Ping timeout: 245 seconds) | 21:51 | |
| vd44 | jaskij[m] but you could also have this configuration generated by systemd | 21:52 |
| jaskij[m] | That's broadly what I'm doing | 21:52 |
| jaskij[m] | But I just finished refactoring one machine for bbappend into a separate include ant it's fifty lines long | 21:53 |
| vd44 | jaskij[m] or even always install all the files, and make the multi-interfaces unit files depends on the interfaces themselves, so that the board with a single interface won't load the configuration for non-existent interfaces | 21:53 |
| jaskij[m] | That's possible? | 21:54 |
| jaskij[m] | Also, what if I want to select, at image definition, between bridged and non-bridged? | 21:54 |
| olani[m] | jaskij: Do you only want to install one of the files on each image, or do you want to install all of them and then use a symlink or something to select the active one? I'm not that good with systemd so do not assume I know how the .network files are used. | 21:54 |
| jaskij[m] | Nah, only installing some of them. I left work just now, but I'll make a mock repo which can be public tomorrow and ping you both to show how it looks like rn, might be easier to understand. | 21:56 |
| jaskij[m] | But only want the actually used files in the image | 21:56 |
| olani[m] | jaskij: Then I'd install all of the files and then separate into separate packages that the image can choose from. | 21:57 |
| vd44 | jaskij[m] maybe ways. You can use a systemd generator reading a configuration file or a kernel command line to generate the given unit files, or you can define a variable in your image recipe used in a ROOTFS_POSTPROCESS_COMMAND function to install the unit files at image creation time. You can then edit this variable in the recipe, the machine | 21:58 |
| vd44 | configuration or somewhere else. | 21:58 |
| vd44 | s/maybe/many/ | 21:58 |
| olani[m] | Don't know why you put it all into the systemd-cond recipe either. It's fine to do one recipe per machine that can be selected with PREFERRED_PROVIDER. | 21:58 |
| olani[m] | s/cond/conf/ | 21:59 |
| jaskij[m] | olani[m]: That's what I'm doing now, but what vd44 proposes seem a bit better | 21:59 |
| jaskij[m] | It just occured to me that I could maybe abuse PACKAGECONFIG or create a similar mechanism | 21:59 |
| olani[m] | Yes, systemd can do many wonderful things :) | 22:00 |
| jaskij[m] | Why I picked it, is that it actually also supports CAN interfaces | 22:01 |
| vd44 | I personally prefer to have everything dynamic if possible, that makes the image recipes simpler. If you do not want all files to be present on the system (even though used given the correct After= and other conditions), then a generator can be used. | 22:01 |
| olani[m] | vd44: I agree. I just don't know how to do it with systemd. | 22:02 |
| jaskij[m] | vd44: For an appliance, sure. But I can't rule out we'll be selling these open, for the client to program. In that case I believe generators might be too convoluted. | 22:04 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 22:05 | |
| vd44 | olani[m] 2 ways: 1) add all files, and set the correct After=sys-subsystem-net-devices-eth1.device for example so that the bridge isn't brought up if eth1 isn't present 2) write a generator which reads e.g. mynetworkmode=bridged kernel parameter and generates the unit files. See man systemd.generator | 22:05 |
| vd44 | jaskij[m] if you only want to keep the configuration at the image level, then ROOTFS_POSTPROCESS_COMMAND += "mynetwork; " mynetwork () { if [ "${MYNETWORK}" = "bridged" ] ; then echo ... > ${IMAGE_ROOTFS}/usr/lib/systemd/... } | 22:09 |
| vd44 | or one function per setting, ROOTFS_POSTPROCESS_COMMAND += "${MYNETWORKTWEAKS}" and set MYNETWORKTWEAKS = "bridged; " in your machine configuration, you get the idea | 22:11 |
| jaskij[m] | Yup | 22:12 |
| *** florian <florian!~florian@dynamic-078-048-039-016.78.48.pool.telefonica.de> has joined #yocto | 22:12 | |
| halstead | moto-timo: I pulled in your patchest and the index is working fine but the rrs portion is failing so I can't take it live. | 22:21 |
| halstead | moto-timo: Want to hack on the rrs code with me and get it Django 2.2 compatible? | 22:22 |
| moto-timo | halstead: absolutely. Do you have logs? Or a reproducer? (Or give me access…) | 22:23 |
| halstead | moto-timo: Sure. I'll email them to you. | 22:24 |
| moto-timo | RRS might be needing more love… | 22:24 |
| halstead | moto-timo: Sent to your gmail. | 22:32 |
| halstead | moto-timo: Would you prefer I paste snippets here? | 22:33 |
| moto-timo | halstead: gmail is great 👍 | 22:33 |
| *** artri <artri!~arca@208.116.134.46> has quit IRC (Ping timeout: 252 seconds) | 22:35 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 22:36 | |
| moto-timo | halstead: I’ll find a way to drop the py2 deps | 22:38 |
| moto-timo | Die die die | 22:38 |
| argonautx | hi, I put a IMAGE_INSTALL += "kernel-devsrc" in my local.conf but got no /usr/src/kernel installation in my target image | 22:41 |
| argonautx | what went wrong? | 22:42 |
| halstead | moto-timo: I suppose for layers that are flagged as python2 only we can just exit immediately instead of standing up the python2 env? | 22:43 |
| RP | reproducibility issues in populate_sysroot down to "just" gobject-introspection, libtool-cross, mesa, perl, python3, rpm and util-linux :/ | 22:45 |
| moto-timo | "just" | 22:45 |
| RP | moto-timo: it was everything earlier so it is looking better, now the more painful problems are emerging from the noise :/ | 22:47 |
| halstead | moto-timo: Fair enough. I didn't look into how the system handles an early return. | 22:47 |
| ndec_ | thanks for whoever suggested https://venueless.org/en/ in the BoF today.. I didn't know about it and it looks great. I will investigate a bit more about it! (Jan I think) | 22:48 |
| moto-timo | RP: maybe we we can discuss perl and python tomorrow in triage | 22:48 |
| moto-timo | halstead: I forgot about the "layers that support python2" wrinkle... | 22:49 |
| RP | moto-timo: sadly I think I'll have to dive into each one and figure out where the differences are | 22:49 |
| RP | e.g. util-linux is in setarch. No idea what beyond that | 22:49 |
| *** florian <florian!~florian@dynamic-078-048-039-016.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 22:50 | |
| RP | moto-timo: python3 is in sysconfigdata | 22:50 |
| RP | moto-timo: perl is in config.sh and Config_heavy.pl | 22:51 |
| moto-timo | RP: that sounds familiar with perl... | 22:51 |
| RP | moto-timo: trouble is this is the sysroot so things can have host paths :/ | 22:52 |
| RP | somehow we need to remove these from the checksums | 22:52 |
| RP | http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=fe046cc125baf3847351b6816e14bcf4e47bbcec is horrible :( | 22:52 |
| jonmason | https://zoom.us/j/99151508871 | 22:57 |
| jonmason | join the OE happy hour! | 22:57 |
| jonmason | we're actually talking about YP stuff | 22:57 |
| vd44 | should IMAGE_BASENAME defaults to ${BPN} instead of ${PN}? | 22:58 |
| *** etam[m] <etam[m]!~etam@user/etam> has left #yocto | 23:03 | |
| RP | JPEW: I'm kind of sad I had to resort to http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=1d0a3111e2f6e296dc4380525bc125034b85d8cc | 23:03 |
| *** ericson2314 <ericson2314!~ericson23@2001:470:69fc:105::70c> has joined #yocto | 23:05 | |
| ericson2314 | does anyone know about newlib-nano | 23:05 |
| ericson2314 | internet says it is afork | 23:05 |
| ericson2314 | but there are nano.specs files in the newlib source | 23:06 |
| ericson2314 | that hint otherwise | 23:06 |
| ericson2314 | yet those have e.g. -lc_nano which doesn't seem to correspond to anything in the rest of newlib, so it is very unclear to me what's going on | 23:06 |
| fray | it's a fork, one that isn't directly compatible with newlib itself.. | 23:07 |
| ericson2314 | thanks | 23:07 |
| fray | I did some looking, and it appears to pretty specialized, for MY usecase it wasn't appropriate.. and the best i found is it seemed pretty out of date.. | 23:07 |
| fray | (I was/am doing some baremetal builds that require a more full featured libc) | 23:07 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 23:07 | |
| ericson2314 | yeah I am trying to do get a way from a vendor's frankenstein SDK | 23:08 |
| ericson2314 | which grab's ARM's prebuilt toolchains among other things | 23:08 |
| fray | everything I do is based on Yocto Project SDKs.. I avoid the ARM, crosstool-ng, etc.. | 23:10 |
| jonmason | arm toolchains are great. get them from meta-arm! | 23:10 |
| ericson2314 | jonmason: everything I do is with Nix / Nixpkgs, but I come here because the kindred spirit :) | 23:11 |
| fray | arm toolchains are great, if you want 15 different multilibs.. ;) | 23:11 |
| fray | I've been trying to convince people since we support 3 (main) ARM CPUs.. maybe our SDK should be those three + r5... ;) | 23:12 |
| fray | not 15.. | 23:12 |
| jonmason | fray: I'm obligated by my employer to say they are perfect in every way | 23:12 |
| ericson2314 | jonmason: are the recipes to create the official binaries public? | 23:12 |
| ericson2314 | I found https://stackoverflow.com/questions/50154137/how-to-rebuild-newlib-and-newlib-nano-of-gnu-arm-embedded-toolchain which I somehow missed before, but the launchpad stuff is abandoned | 23:13 |
| jonmason | ericson2314: to create, no. we have recipes that use the official binaries and we have recipes that use the arm gcc source | 23:13 |
| fray | the Yocto Project can build a newlib SDK.. note if you need a specifically configured libgloss or newlib you may have to adjust some things | 23:14 |
| ericson2314 | ok thanks both of you | 23:14 |
| ericson2314 | I will see if there is anything non-marketting with this arm website, heh :) | 23:14 |
| jonmason | jsut go to the layer index and look for meta-arm-toolchain | 23:17 |
| ericson2314 | thanks | 23:17 |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 23:27 | |
| ericson2314 | per https://github.com/crosstool-ng/crosstool-ng/pull/1447/files and https://github.com/ecbrown/guix/commit/a299a8992cb96575db397122f9e2f82cbb96286e it seems as of late ARM is not using a fork but just passing different flags | 23:30 |
| *** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 23:33 | |
| *** u1106 <u1106!~quassel@ec2-18-193-68-189.eu-central-1.compute.amazonaws.com> has joined #yocto | 23:36 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!