*** hpsy1 <hpsy1!~hpsy@92.118.12.22> has joined #yocto | 00:06 | |
*** hpsy <hpsy!~hpsy@92.118.12.22> has quit IRC | 00:08 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 01:09 | |
*** gpanders <gpanders!~gpanders@c-73-228-7-205.hsd1.nm.comcast.net> has quit IRC | 01:16 | |
*** gpanders <gpanders!~gpanders@c-73-228-7-205.hsd1.nm.comcast.net> has joined #yocto | 01:17 | |
zeddii | moto-timo: yah. but still hard to find. I just built the exact same hash as the working k3s reference from rancher, crashloop. | 01:24 |
---|---|---|
zeddii | so that means it is something in our go compiler or config. | 01:24 |
*** pung_ <pung_!~BobPungar@187.113.149.177> has joined #yocto | 01:29 | |
*** BobPungartnik <BobPungartnik!~BobPungar@187.113.149.177> has quit IRC | 01:31 | |
*** kaspter <kaspter!~Instantbi@180.168.140.162> has joined #yocto | 01:54 | |
*** Kyubi <Kyubi!~Kyubi@2601:640:103:f36e:7d19:9c46:eae8:7560> has joined #yocto | 01:54 | |
*** bps3 <bps3!~bps@80.71.142.18> has joined #yocto | 01:58 | |
*** pung_ <pung_!~BobPungar@187.113.149.177> has quit IRC | 02:07 | |
*** pung_ <pung_!~BobPungar@187.113.149.177> has joined #yocto | 02:07 | |
*** Kyubi <Kyubi!~Kyubi@2601:640:103:f36e:7d19:9c46:eae8:7560> has quit IRC | 02:25 | |
moto-timo | zeddii: I am still trying to figure out why k9s bitches about protobuf and other random fs perms bullshyte | 02:38 |
*** gpanders <gpanders!~gpanders@c-73-228-7-205.hsd1.nm.comcast.net> has quit IRC | 02:39 | |
*** gpanders <gpanders!~gpanders@c-73-228-7-205.hsd1.nm.comcast.net> has joined #yocto | 02:39 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 02:42 | |
*** Kyubi <Kyubi!~Kyubi@149.199.62.128> has joined #yocto | 02:43 | |
*** bps3 <bps3!~bps@80.71.142.18> has quit IRC | 03:08 | |
*** bps <bps!~bps@80.71.142.18> has joined #yocto | 03:14 | |
zeddii | hah. sounds painful. | 03:14 |
zeddii | I'm spelunking in the k3s build scripts to see if the recipe is missing something .. nothing obvious so far. | 03:15 |
*** roussinm <roussinm!~mroussin@bras-base-qubcpq0336w-grc-33-174-93-106-232.dsl.bell.ca> has quit IRC | 03:28 | |
*** ahadi <ahadi!~ahadi@89.244.127.240> has quit IRC | 03:46 | |
*** pung_ <pung_!~BobPungar@187.113.149.177> has quit IRC | 03:47 | |
*** ahadi <ahadi!~ahadi@i5E86AF1C.versanet.de> has joined #yocto | 03:47 | |
*** BobPungartnik <BobPungartnik!~BobPungar@187.113.149.177> has joined #yocto | 03:47 | |
*** kaspter <kaspter!~Instantbi@180.168.140.162> has quit IRC | 03:52 | |
*** kaspter <kaspter!~Instantbi@180.168.140.162> has joined #yocto | 03:52 | |
*** Kyubi <Kyubi!~Kyubi@149.199.62.128> has quit IRC | 03:54 | |
*** Kyubi <Kyubi!~Kyubi@149.199.62.128> has joined #yocto | 03:55 | |
moto-timo | zeddii: trust me, I stared at it for a while and found nothing | 04:21 |
zeddii | I'm trying to find exactly how the reference one is built. ours is simply garbage. | 04:21 |
zeddii | drop in the k3s binary, everything else the same. magic. | 04:21 |
zeddii | I'm building the exact same git hash, so it has to be something else in the cross build breaking it, or a config. | 04:22 |
moto-timo | I know. I fuckng hate that voodooo bullshit | 04:22 |
zeddii | the k3s reference one is static, ours is dynamic. That implies CGO isn't being used, but yet, I can't build without CGO and can't get it to build statically otherwise. | 04:22 |
zeddii | I loathe the way go builds | 04:23 |
moto-timo | #2020 #dumpsterfire | 04:23 |
moto-timo | go can just go | 04:23 |
moto-timo | like why does k0s build gloriously the first time and then BITCH the xecond time? | 04:23 |
moto-timo | f' you | 04:23 |
zeddii | yup. 11pm on a sunday, I'm moving off to call it a day. will work on this during the day tomorrow. | 04:24 |
moto-timo | I successfully built kicad nightly on a raspberrypi400 | 04:24 |
moto-timo | I have spoken | 04:24 |
zeddii | :D | 04:24 |
moto-timo | I thought it was Monday | 04:24 |
moto-timo | FUck me | 04:25 |
zeddii | hahah. blame your sabattical! | 04:25 |
* moto-timo has lost his filter... forgive me it is sabbatical and #2020 | 04:25 | |
moto-timo | lol | 04:25 |
zeddii | I'm going to drool over some netflix and maybe get inspired to try another tactic tomorrow! | 04:25 |
zeddii | catch you later! | 04:25 |
moto-timo | g'night zeddii | 04:25 |
moto-timo | may the force be with you | 04:25 |
moto-timo | as always, ping me with random crap | 04:26 |
*** pung_ <pung_!~BobPungar@187.113.149.177> has joined #yocto | 04:45 | |
*** BobPungartnik <BobPungartnik!~BobPungar@187.113.149.177> has quit IRC | 04:45 | |
*** BobPungartnik <BobPungartnik!~BobPungar@187.113.149.177> has joined #yocto | 04:50 | |
*** pung_ <pung_!~BobPungar@187.113.149.177> has quit IRC | 04:52 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto | 05:12 | |
*** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 05:20 | |
*** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 05:22 | |
*** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 05:24 | |
*** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC | 05:27 | |
*** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 05:32 | |
*** kaspter <kaspter!~Instantbi@180.168.140.162> has quit IRC | 05:50 | |
*** kaspter <kaspter!~Instantbi@180.168.140.162> has joined #yocto | 05:51 | |
*** Kyubi <Kyubi!~Kyubi@149.199.62.128> has quit IRC | 05:54 | |
*** Kyubi <Kyubi!~Kyubi@149.199.62.128> has joined #yocto | 05:55 | |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto | 05:56 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 05:59 | |
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC | 06:01 | |
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto | 06:02 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto | 06:10 | |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC | 06:13 | |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto | 06:15 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 06:16 | |
*** jobroe <jobroe!~manjaro-u@p579eb713.dip0.t-ipconnect.de> has joined #yocto | 06:19 | |
*** hpsy1 <hpsy1!~hpsy@92.118.12.22> has quit IRC | 06:19 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto | 06:27 | |
*** davidinux <davidinux!~davidinux@185.93.183.164> has joined #yocto | 06:28 | |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC | 06:30 | |
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 06:38 | |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto | 06:48 | |
*** jleightcap1 <jleightcap1!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has quit IRC | 06:50 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 06:51 | |
*** jleightcap1 <jleightcap1!~jleightca@c-174-60-161-106.hsd1.pa.comcast.net> has joined #yocto | 06:52 | |
*** Shikadi` <Shikadi`!~Shikadi@136.27.30.135> has quit IRC | 06:59 | |
zyga | hello :) | 07:00 |
*** zyga <zyga!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC | 07:00 | |
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 07:00 | |
*** TobSnyder <TobSnyder!~schneider@p54aa8f7f.dip0.t-ipconnect.de> has quit IRC | 07:07 | |
*** camus <camus!~Instantbi@180.168.140.162> has joined #yocto | 07:10 | |
*** kaspter <kaspter!~Instantbi@180.168.140.162> has quit IRC | 07:11 | |
*** camus is now known as kaspter | 07:11 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto | 07:12 | |
*** minimaxwell <minimaxwell!~minimaxwe@apoitiers-259-1-26-122.w90-55.abo.wanadoo.fr> has joined #yocto | 07:12 | |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC | 07:15 | |
*** RobertBerger <RobertBerger!~rber@ppp-2-86-143-170.home.otenet.gr> has joined #yocto | 07:16 | |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto | 07:18 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 07:21 | |
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto | 07:22 | |
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC | 07:23 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:23 | |
mihai | morning | 07:32 |
erbo | morning! | 07:38 |
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-xnbsyfusougticbk> has joined #yocto | 07:40 | |
*** frsc <frsc!~frsc@mue-88-130-78-028.dsl.tropolys.de> has joined #yocto | 07:41 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 07:41 | |
*** frwol <frwol!~frwol@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 07:44 | |
*** Kyubi <Kyubi!~Kyubi@149.199.62.128> has quit IRC | 07:44 | |
LetoThe2nd | yo dudX | 07:48 |
*** creich <creich!~creich@p200300f6af0a9910000000000000039b.dip0.t-ipconnect.de> has quit IRC | 07:49 | |
*** creich <creich!~creich@p200300f6af0a9910000000000000039b.dip0.t-ipconnect.de> has joined #yocto | 07:50 | |
*** beneth <beneth!~beneth@irc.beneth.fr> has joined #yocto | 07:56 | |
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has joined #yocto | 07:57 | |
*** fl0v0 <fl0v0!~fvo@89.244.120.6> has joined #yocto | 07:57 | |
RobertBerger | morning | 08:03 |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 08:08 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 08:09 | |
*** tnovotny <tnovotny!~tnovotny@176-74-132-138.netdatacomm.cz> has joined #yocto | 08:12 | |
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto | 08:13 | |
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC | 08:14 | |
*** armpit <armpit!~armpit@2601:202:4180:a5c0:c584:dc9f:dcf0:9e06> has quit IRC | 08:15 | |
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/matrix.org/x-attydgvgozghmtvf> has quit IRC | 08:15 | |
*** stefan-schmidt[m <stefan-schmidt[m!stefan-sch@gateway/shell/matrix.org/x-lqabcrkzhkqgomld> has quit IRC | 08:16 | |
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto | 08:16 | |
*** stefan-schmidt[m <stefan-schmidt[m!stefan-sch@gateway/shell/matrix.org/x-gddespdwozxqxczh> has joined #yocto | 08:16 | |
*** jleightcap1 <jleightcap1!~jleightca@c-174-60-161-106.hsd1.pa.comcast.net> has quit IRC | 08:16 | |
*** jobroe <jobroe!~manjaro-u@p579eb713.dip0.t-ipconnect.de> has quit IRC | 08:16 | |
*** MiskaX <MiskaX!uy2f4cec20@rankki.sonarnerd.net> has quit IRC | 08:16 | |
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 08:16 | |
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC | 08:16 | |
*** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-08-142-114-156-131.dsl.bell.ca> has quit IRC | 08:16 | |
*** gonkulator <gonkulator!~brandon@75.71.150.20> has quit IRC | 08:16 | |
*** alinucs <alinucs!~abo@215.ip-51-38-235.eu> has quit IRC | 08:16 | |
*** cengiz_io <cengiz_io!~cengiz_io@159.89.7.238> has quit IRC | 08:16 | |
*** dirbaio <dirbaio!~dirbaio@nsmbhd.net> has quit IRC | 08:16 | |
*** nslu2-log__ <nslu2-log__!~nslu2-log@leia.nas-admin.org> has quit IRC | 08:16 | |
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-078-042-006-202.hsi3.kabel-badenwuerttemberg.de> has quit IRC | 08:16 | |
*** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has quit IRC | 08:16 | |
*** armpit <armpit!~armpit@2601:202:4180:a5c0:517b:4767:4af3:9059> has joined #yocto | 08:16 | |
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/matrix.org/x-trvknjhaobvsjeej> has joined #yocto | 08:17 | |
*** oberstet <oberstet!~oberstet@213.170.219.39> has joined #yocto | 08:17 | |
*** ahadi <ahadi!~ahadi@i5E86AF1C.versanet.de> has quit IRC | 08:19 | |
*** ahadi <ahadi!~ahadi@i5E86AF1C.versanet.de> has joined #yocto | 08:21 | |
*** jleightcap1 <jleightcap1!~jleightca@c-174-60-161-106.hsd1.pa.comcast.net> has joined #yocto | 08:22 | |
*** jobroe <jobroe!~manjaro-u@p579eb713.dip0.t-ipconnect.de> has joined #yocto | 08:22 | |
*** MiskaX <MiskaX!uy2f4cec20@rankki.sonarnerd.net> has joined #yocto | 08:22 | |
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 08:22 | |
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto | 08:22 | |
*** ssajal <ssajal!~ssajal@bras-base-otwaon1146w-grc-08-142-114-156-131.dsl.bell.ca> has joined #yocto | 08:22 | |
*** gonkulator <gonkulator!~brandon@75.71.150.20> has joined #yocto | 08:22 | |
*** alinucs <alinucs!~abo@215.ip-51-38-235.eu> has joined #yocto | 08:22 | |
*** cengiz_io <cengiz_io!~cengiz_io@159.89.7.238> has joined #yocto | 08:22 | |
*** dirbaio <dirbaio!~dirbaio@nsmbhd.net> has joined #yocto | 08:22 | |
*** nslu2-log__ <nslu2-log__!~nslu2-log@leia.nas-admin.org> has joined #yocto | 08:22 | |
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-078-042-006-202.hsi3.kabel-badenwuerttemberg.de> has joined #yocto | 08:22 | |
*** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has joined #yocto | 08:22 | |
*** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC | 08:22 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:23 | |
*** mckoan|away is now known as mckoan | 08:23 | |
mckoan | good morning | 08:23 |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto | 08:24 | |
*** pharaon2502 <pharaon2502!~manjaro-u@dh207-120-145.xnet.hr> has joined #yocto | 08:30 | |
*** jleightcap1 <jleightcap1!~jleightca@c-174-60-161-106.hsd1.pa.comcast.net> has quit IRC | 08:30 | |
*** jleightcap1 <jleightcap1!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has joined #yocto | 08:32 | |
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-078-042-006-202.hsi3.kabel-badenwuerttemberg.de> has quit IRC | 08:33 | |
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-078-042-006-202.hsi3.kabel-badenwuerttemberg.de> has joined #yocto | 08:33 | |
*** lukma <lukma!~lukma@89-64-25-12.dynamic.chello.pl> has quit IRC | 08:34 | |
*** agust <agust!~agust@p5483356f.dip0.t-ipconnect.de> has joined #yocto | 08:42 | |
*** jleightcap1 <jleightcap1!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has quit IRC | 08:50 | |
*** lukma <lukma!~lukma@89-64-25-12.dynamic.chello.pl> has joined #yocto | 08:52 | |
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:5178:619c:fc92:5a85> has joined #yocto | 09:10 | |
qschulz | hello there | 09:11 |
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:5178:619c:fc92:5a85> has quit IRC | 09:13 | |
LetoThe2nd | yo qschulz | 09:19 |
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:26 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:29 | |
*** manuel__ <manuel__!~manuel@089144218092.atnat0027.highway.a1.net> has joined #yocto | 09:35 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 09:48 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 09:48 | |
rob_w | hi there .. i got a issue with a simple makefile situation .. i cannot get a correct Makefile.am which compiles my objects in parallel and not in a serial way | 09:54 |
rob_w | some trys fail as the toolchain then misses paths , some fail because my lack of autotool knowledge | 09:54 |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 09:58 | |
LetoThe2nd | rob_w: any particular requirement nailing you down on autotools then, if you're already having problems with it? | 09:59 |
*** kaspter <kaspter!~Instantbi@180.168.140.162> has quit IRC | 10:00 | |
*** kaspter <kaspter!~Instantbi@180.168.140.162> has joined #yocto | 10:00 | |
rob_w | itts a understanding issue i think .. .i got a Makefile.am where i place foo_SOURCES = 1.c 2.c 3.c etc then foo_LDADD and bin_PROGRAMS = foo | 10:01 |
rob_w | but i want that 1.c 2.c 3.c etc are compile via make -j X .. in parallel so to speak | 10:01 |
rob_w | but it compiles one after the other | 10:01 |
rob_w | so i understand that i would need to specify the 1.o 2.o 3.o as seperate targets ? | 10:02 |
LetoThe2nd | my knowledge there is pretty limited too, but i dont think that this is the case. | 10:04 |
*** Bunio_FH <Bunio_FH!~bunio@188.146.131.212.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 10:12 | |
*** bhstalel <bhstalel!c15f633e@193.95.99.62> has joined #yocto | 10:20 | |
bhstalel | Hi, I don't want to interrupt an active conversation but I have an urgent question: | 10:21 |
bhstalel | I have an LCD display | 10:21 |
bhstalel | Where to put the video parameter ? in uboot devicetree bootargs ? | 10:22 |
bhstalel | Or somewhere in the kernel ? | 10:22 |
bhstalel | The LCD interface in MIPI DSI | 10:23 |
qschulz | video parameters? | 10:25 |
mckoan | bhstalel: machine name ? | 10:28 |
bhstalel | I'm working on IMX8MM and I have an LCD display , and I'm told to add boot parameter to the kernel like this : "video=mxcfb0:dev=mipi_dsi,if=RGB24" , but I don't know where to add it | 10:29 |
mckoan | bhstalel: in u-boot, it is the kernel command line | 10:33 |
qschulz | put it into the bootargs u-boot env variable | 10:33 |
*** LocutusOfBorg <LocutusOfBorg!~locutusof@ubuntu/member/locutusofborg> has quit IRC | 10:34 | |
bhstalel | Okay , I'll look into it, thanks all :)))) | 10:35 |
rob_w | well my problem just resolved .. i realized my code would not gain compile speed even with parallel make -j .. thx anyway | 10:40 |
rob_w | 90% of my time is coming from one particular .c file .. so until i split this up it is what it is | 10:41 |
*** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #yocto | 10:47 | |
*** LocutusOfBorg <LocutusOfBorg!~locutusof@ubuntu/member/locutusofborg> has joined #yocto | 10:47 | |
*** BobPungartnik <BobPungartnik!~BobPungar@187.113.149.177> has quit IRC | 10:49 | |
*** dleppich <dleppich!~Thunderbi@p5098be52.dip0.t-ipconnect.de> has joined #yocto | 10:53 | |
*** dleppich <dleppich!~Thunderbi@p5098be52.dip0.t-ipconnect.de> has joined #yocto | 11:07 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 11:13 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 11:13 | |
*** chris456 <chris456!4e378c34@dynamic-078-055-140-052.78.55.pool.telefonica.de> has joined #yocto | 11:22 | |
chris456 | i want to compile a go program and i got an erro: https://codeshare.io/GkV64x | 11:31 |
chris456 | do i have to add a specific "go"-layer or should it work out of the box? | 11:32 |
otavio | RP: can you take a look at "Strange segfault on native Go binaries" on ml? | 11:32 |
otavio | chris456: on recent Yocto Project releases, we have Go support on OE-Core | 11:33 |
RP | otavio: I had seen it. Are you using sstate generated by the nixos system on the ubuntu one? | 11:33 |
RP | otavio: I'd suspect some kind of patchelf problem, particularly as nixos uses patchelf extensively itself | 11:34 |
chris456 | octavio: https://layers.openembedded.org/layerindex/recipe/60594/ <- this one? | 11:36 |
otavio | RP: no, I did it all inside the docker | 11:36 |
otavio | RP: I did not run it inside the nixos. As I mentioned to khem I am using a Docker container with Ubuntu 20.04 | 11:37 |
*** habing <habing!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has joined #yocto | 11:48 | |
otavio | RP: I believe it is reproducible there. | 11:48 |
*** zandrey <zandrey!~zandrey@193.8.40.126> has joined #yocto | 11:56 | |
RP | otavio: at that point you probably have to try and see if patchelf is breaking the binary... | 11:56 |
otavio | RP: can you tell me where to look? | 11:59 |
otavio | I can check, for sure | 11:59 |
RP | otavio: have a look at the code in uninative.bbclass. You'd want to try the binary before and after the patchelf --set-interpreter call | 12:03 |
RP | otavio: can you also check that the version of glibc used in uninative is newer or equal to the glibc version on the system you're building on? | 12:04 |
RP | otavio: there are also chrpath calls from chrpath.bbclass which may edit the binary so those could also be a potential cause | 12:05 |
*** tgoodwin <tgoodwin!~tgoodwin@pool-100-16-74-100.bltmmd.fios.verizon.net> has joined #yocto | 12:28 | |
*** kaspter <kaspter!~Instantbi@180.168.140.162> has quit IRC | 12:43 | |
*** kaspter <kaspter!~Instantbi@180.168.140.162> has joined #yocto | 12:43 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 13:04 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 13:04 | |
*** marc1 <marc1!~marc@69.4.212.132> has quit IRC | 13:06 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 13:14 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 13:14 | |
*** bps <bps!~bps@80.71.142.18> has quit IRC | 13:21 | |
*** hpsy <hpsy!~hpsy@92.118.12.22> has joined #yocto | 13:28 | |
RP | rburton: I think the syslinux changes aren't happy: https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/1654/steps/14/logs/stdio | 13:33 |
RP | I'll reply on list so aesh can see it | 13:37 |
*** hpsy <hpsy!~hpsy@92.118.12.22> has quit IRC | 13:39 | |
*** kaspter <kaspter!~Instantbi@180.168.140.162> has quit IRC | 13:42 | |
rburton | bah | 13:46 |
rburton | isohybrid: not found | 13:47 |
rburton | well at least it wasn't something i did to syslinux directly | 13:47 |
RP | rburton: doesn't look too serious to fix | 13:54 |
rburton | you say that | 13:54 |
rburton | this is syslinux | 13:54 |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:54 | |
RP | rburton: I'm trying to be positive ;-) | 13:55 |
RP | rburton: I can tell you you're doomed if you like ;-) | 13:55 |
*** PaowZ <PaowZ!~vince@2a01:e0a:144:d020:806a:e75f:3191:328d> has quit IRC | 13:58 | |
rburton | kicking a selftest run to verify the patches before submitting | 14:03 |
*** PaowZ <PaowZ!~vince@2a01:e0a:144:d020:6d94:8140:daf2:8421> has joined #yocto | 14:09 | |
*** luneff <luneff!~yury@80.72.17.178> has joined #yocto | 14:20 | |
*** marc1 <marc1!~marc@modemcable182.194-37-24.static.videotron.ca> has joined #yocto | 14:25 | |
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 14:26 | |
*** ecdhe_ is now known as ecdhe | 14:31 | |
*** Bunio_FH <Bunio_FH!~bunio@188.146.131.212.nat.umts.dynamic.t-mobile.pl> has quit IRC | 14:32 | |
*** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 14:42 | |
tardyp | Hello. currently integrating smack on one of our projects. do we really have to create 1600 bbappend files, one for each recipe we build in? | 14:45 |
tardyp | each bbappend would add the proper extended attribute to the installed files | 14:46 |
qschulz | don't know about smack but that sounds like a good use for something handled on the distro level? | 14:50 |
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 14:50 | |
rburton | tardyp: there's a worked example of using smack in tizen/iot-dev-kit if you dig out the old repos | 14:51 |
rburton | not sure of anyone using it since then though | 14:51 |
RP | tardyp: are the bbappend files similar and boilerplate? If so there are other ways you could inject into all recipes | 14:52 |
RP | if they're custom to each recipe that gets harder | 14:52 |
tardyp | we need to split our fs into a dozen domain, and then inject the right xattr to each file according to their domain | 14:53 |
rburton | are there any package managers that successfully package up extended attributes? | 14:54 |
tardyp | I saw an old email saying it wasn't obvious | 14:54 |
RP | tardyp: there are hooks during packaging for example where you could hook in such a generic processing function | 14:56 |
smurray | AGL uses postinst to do the labeling on first boot | 14:57 |
tardyp | https://www.irccloud.com/pastebin/cbCrbAJm/ | 14:59 |
tardyp | I saw something like this indeed. not sure if this is really scalable | 15:00 |
*** roussinm <roussinm!~mroussin@bras-base-qubcpq0336w-grc-33-174-93-106-232.dsl.bell.ca> has joined #yocto | 15:00 | |
rburton | not sure how AGL does it, but a class you can globally inherit to write a postinst would be fairly simple to write | 15:00 |
tardyp | yes, that was RP suggested I think. I worry it will increase the first boot, and the first boot is in the fab, and you don't want that to take too much time. | 15:01 |
smurray | rburton: the stuff in AGL currently does the base labels via a base-files bbappend, per-app stuff is done when they're installed at run-time (please don't ask ;) ) | 15:01 |
*** luneff <luneff!~yury@80.72.17.178> has quit IRC | 15:02 | |
rburton | smurray: i've done incredibly well by not asking anything about AGL so far ;) | 15:02 |
smurray | rburton: heh | 15:02 |
smurray | tardyp: one approach would be a task that does it via qemu, I've had idle thoughts about that wrt SELinux + read-only-root, but not tried doing it | 15:04 |
tardyp | mkfs.ext4 is not capable of creating xattr at the beginning, right? | 15:05 |
tardyp | I mean at the image creation time | 15:06 |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 15:13 | |
*** stephano <stephano!~stephano@73.240.0.134> has joined #yocto | 15:17 | |
*** tnovotny <tnovotny!~tnovotny@176-74-132-138.netdatacomm.cz> has quit IRC | 15:17 | |
smurray | tardyp: not that I'm aware of | 15:25 |
*** kaspter <kaspter!~Instantbi@2409:8a1e:911b:1000:54:c66b:ba18:66cc> has joined #yocto | 15:29 | |
dl9pf | hmm ... mkfs.ext4 -O flag ? maybe ? | 15:31 |
*** Konsgn <Konsgn!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 15:34 | |
*** Konsgn <Konsgn!~Konsgnx3@unafiliated/joyseph> has joined #yocto | 15:34 | |
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has quit IRC | 15:43 | |
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto | 15:43 | |
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC | 15:44 | |
smurray | dl9pf: that's for filesystem features AFAIK? | 15:46 |
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto | 15:47 | |
smurray | I think one sticking point wrt doing it outside of qemu is that assumes the host has all the xattr, etc. support, which you'd hope would be the case, but... | 15:48 |
smurray | and the easiest thing that comes to mind is loopback mounting, which seems potentially problematic wrt doing it as non-root | 15:52 |
*** zandrey <zandrey!~zandrey@193.8.40.126> has quit IRC | 15:52 | |
*** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 15:53 | |
dl9pf | right, right. | 16:01 |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-zlurlwjkoisvsmab> has joined #yocto | 16:02 | |
tardyp | indeed. qemu is hard to run in the CI, because you need kvm access for best perf. Maybe we can look at user mode linux | 16:04 |
tardyp | both options looks quite complicated for the usecase :-/ | 16:04 |
smurray | tardyp: right, there's a reason why most distros end up doing it at boot | 16:13 |
smurray | tardyp: even for read-only-root, I could imagine maybe just doing it from initramfs before mounting r/o, though that doesn't work for some usecases | 16:15 |
*** jobroe <jobroe!~manjaro-u@p579eb713.dip0.t-ipconnect.de> has quit IRC | 16:20 | |
*** Kyubi <Kyubi!~Kyubi@2601:640:109:58ea:b15c:c47f:eaa3:f5c4> has joined #yocto | 16:21 | |
*** Kyubi <Kyubi!~Kyubi@2601:640:109:58ea:b15c:c47f:eaa3:f5c4> has quit IRC | 16:27 | |
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 16:29 | |
*** Kyubi <Kyubi!~Kyubi@149.199.62.131> has joined #yocto | 16:31 | |
*** pit82 <pit82!5d8510a6@dynamic-093-133-016-166.93.133.pool.telefonica.de> has joined #yocto | 16:38 | |
*** pit82 is now known as onkelpit | 16:39 | |
*** RobertBerger <RobertBerger!~rber@ppp-2-86-143-170.home.otenet.gr> has quit IRC | 16:44 | |
*** RobertBerger <RobertBerger!~rber@128.90.148.128> has joined #yocto | 16:45 | |
*** frsc <frsc!~frsc@mue-88-130-78-028.dsl.tropolys.de> has quit IRC | 16:49 | |
*** kaspter <kaspter!~Instantbi@2409:8a1e:911b:1000:54:c66b:ba18:66cc> has quit IRC | 16:54 | |
*** camus <camus!~Instantbi@183.192.136.178> has joined #yocto | 16:54 | |
armpit | zeddii, really | 16:54 |
zeddii | really! | 16:56 |
*** camus is now known as kaspter | 16:56 | |
zeddii | :D | 16:56 |
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has quit IRC | 16:59 | |
*** marler8997 <marler8997!~marler899@96-18-174-190.cpe.sparklight.net> has joined #yocto | 17:02 | |
marler8997 | Is there a way to specify a sub directory in a SRC_URI resource such that yocto only hashes what is inside the subdirectory? | 17:02 |
*** frwol <frwol!~frwol@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC | 17:03 | |
*** beneth <beneth!~beneth@irc.beneth.fr> has left #yocto | 17:03 | |
*** fl0v0 <fl0v0!~fvo@89.244.120.6> has quit IRC | 17:04 | |
qschulz | marler8997: you can give a directory to SRC_URI yes | 17:05 |
qschulz | file://dir or file://dir/ will work | 17:05 |
qschulz | everything in it will be taken | 17:05 |
qschulz | DO NOT USE PATTERNS | 17:06 |
qschulz | I repeat, DO NOT USE PATTERNS (globs, regexp, whatever) it does NOT work | 17:06 |
marler8997 | we have a repository where we keep around 40 small projects | 17:06 |
marler8997 | we put the SRC_URI for this repository in a class so all the recipes just inherit from this class and we only update one location | 17:06 |
fray | you have to hash the whole repository, unless you break it up and check in branches.. (part of the reason mixng projects is a bad idea) | 17:07 |
marler8997 | but that means when any one project changes, the hash changes for all the projects | 17:07 |
fray | yup, which is why you don't do that.. there is no other way, on an SCM other then say 'this is the checkout point' | 17:07 |
marler8997 | I don't think *yocto doesn't support this use case* means *this is a bad use case* | 17:07 |
*** habing <habing!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has quit IRC | 17:07 | |
marler8997 | first, I haven't established yet whether yocto support this or not | 17:07 |
fray | Yocto Project CAN share a single SCM across recipes.. easily.. we do it all the time | 17:08 |
marler8997 | yes I know, that's what we're doing | 17:08 |
fray | However, it CAN'T distinguish one portion of a checkout from another.. it CAN distinuigh a branch from another branch or commit to another commit | 17:08 |
*** chris456 <chris456!4e378c34@dynamic-078-055-140-052.78.55.pool.telefonica.de> has quit IRC | 17:09 | |
fray | So either you need separate commits for each chunk (branch usually), or you can't do it.. It really is a bad way to use a repository, but people do it all the time.. the problem when doing this is more then just YP integration, it affects all CI systems that can short-path and just check for an update based on the top of the tree.. (this isn't git specific) | 17:09 |
marler8997 | what alternative would you suggest? | 17:10 |
marler8997 | it's over 40 small tools libraries, with alot of cross dependencies, putting them in one repo makes it convenient to build/test them because of all the dependencies | 17:11 |
fray | What I've done in the past is break the repsoitory up.. If it's a git repository there are ways of breaking it up AND preserving history (if you need history). Some of this can be done automatically, so if your process/developers insist on a combined SCM you can do that and automate the individual prpoject ones.. but that can be troublesome.. | 17:11 |
*** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 17:11 | |
fray | note breaking the repository up == into branches OR separage SCMs.. (I've done both) | 17:11 |
marler8997 | We can break it up into 40 repositories, but that's alot of work, it's alot of work to maintain 40 repositories with 40 different sets of reviewers and permissions | 17:11 |
fray | depends on your backend systems.. I've certainly done that before and it wasn't, but we have tooling in place to assist.. gitolite was one case, github (enterprise) was another.. | 17:12 |
fray | but if it's simply a permissions management concern, you can do it by branch instead.. | 17:12 |
marler8997 | that's going to be alot more work than the problem we have now, we'd be trading one problem for a much bigger problem | 17:12 |
*** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 17:13 | |
fray | module1/master module2/master module3/master then have a script that generates these adn keeps them up to date as post-process checkins | 17:13 |
smurray | perhaps just live with building it in a single recipe? If pieces of it are interdependent, you're triggering a bunch of rebuilds anyways if things are set up right... | 17:13 |
marler8997 | smurray, that doesn't solve the problem either because the entire recipe gets rebuilt even when only one project gets modified | 17:14 |
fray | You have to remember SCM / branch / commit is ONE project.. | 17:14 |
smurray | marler8997: such is life, you can't have everything | 17:14 |
fray | directories are not projects, they're part of them.. but it's up to your infrastructure and desired way to work | 17:14 |
marler8997 | that's not really a helpful pience of advice lol | 17:14 |
marler8997 | I ask a question, "how do I do this" and I get an answer "you can't have everything" | 17:15 |
marler8997 | fray so far you haven't given me an alternative that is any better | 17:15 |
fray | there is no standard way in SCM systems to say 'give me this commit, but only pay attention to the items in directory XYZ'... UNLESS you pull the SCM _first_ and then do something like (in git) git log | 17:15 |
marler8997 | you can say that "directories are not projects" but that doesn't mean it's true | 17:15 |
marler8997 | in our case, we have a single repository with multiple small projects inside it | 17:15 |
fray | WIth the way an SCM (at a high level) is designed, an SCM is a 'project'.. an independent group of things.. | 17:16 |
fray | Yes, and that happens.. but it's the cause of the problem in this case and can make management more difficult.. but I understand why people do this. | 17:16 |
marler8997 | ok you've answered my question | 17:16 |
fray | nothing more that I can suggest other then review it and break it apart.. long term it will be better | 17:16 |
marler8997 | I may add a prepend task to do fetch that allows me to specify a SRC_URL with a repository and a subdirectory | 17:17 |
fray | You would be overriding the bitbake download, which means no cached download sources | 17:17 |
marler8997 | I could have each project provide the hash to the subdirectory, then after it's fetched it could verify the hash | 17:17 |
fray | This may work internally for you, but won't work in the general case | 17:17 |
marler8997 | yocto's git downloader is horrible anyway | 17:18 |
fray | A lot of people using YP require downloads to come from a local cache directory.. so by passing that will make it impossible to use | 17:18 |
marler8997 | it downloads the whole repository, then creates a compressed archive from it! | 17:19 |
fray | which part? | 17:19 |
zeddii | lol | 17:19 |
fray | You can do shallow clones you knwo | 17:19 |
marler8997 | we build webkit inside yocto, it takes 20 minutes to download, then over 40 minutes to create the compressed archive | 17:19 |
fray | if you don't want the history for any reason (or a limited amount) just enable shallow cloning | 17:19 |
marler8997 | it's the creating the archive that takes the most time (not the download) | 17:20 |
fray | Again, shallow clone vs full clone.. full clone is default | 17:20 |
marler8997 | irrelevant to the archive creation | 17:20 |
fray | No.. | 17:20 |
fray | shallow clones are much smaller, as they don't have any hiustory behind them | 17:20 |
fray | you can also avoid creating an archive and use the git directly as well | 17:20 |
fray | these are simply switches to be flipped | 17:21 |
marler8997 | well I figured it was smart enough not to archive the git history | 17:21 |
marler8997 | are you saying it archives the .git directory as well? | 17:21 |
kergoth | marler8997: if you don't want the archives for mirror population, disable mirror tarball generation | 17:21 |
kergoth | or switch to shallow tarball usage, as fray said | 17:21 |
fray | Yes, the whole point of the downloads is reproducibility with no network access.. so it ONLY archives teh .git directory | 17:21 |
kergoth | somewhere in your setup enables BB_GENERATE_MIRROR_TARBALLS. if you don't want it, don't use it | 17:21 |
fray | turn off git archives, and it won't archive them.. | 17:21 |
fray | turn on shallow cloning and it will only fetch a limited set of commits.. | 17:22 |
marler8997 | it only archive the .git directory...what? | 17:22 |
marler8997 | that's definitely not what I remember seeing in the logs and the source | 17:22 |
fray | cost of the first is you have to store/distribute directories intead of tarballs.. cost of the second you lose history if you are working on the component | 17:22 |
marler8997 | I saw that it archives the source, then extracts that archive into WORKDIR | 17:22 |
fray | What I am referring to is specific to git repositories.. | 17:22 |
marler8997 | yes, I'm only talking about git repositories as well | 17:23 |
fray | other SCMs may work different | 17:23 |
rburton | marler8997: maybe explain exactly what steps you're talking about | 17:23 |
fray | ya, the system does 'git clone --bare .....' takes the result (and if tarballs are enabled) will then tar up those contents.. | 17:23 |
marler8997 | when you specify a git:// in SRC_URI, yocto downloads the git respository to some global location, then it archives that repository into a .tar.xz (which takes 40 minutes for webkit), then it extracts that archive into WORKDIR | 17:24 |
marler8997 | I created a "fastgit.bbclass" that uses a different mechanism and saved the 40 minutes on our webkit build | 17:24 |
fray | yes, it downloads, via 'git clone --bare <url>' and archives what you did.. you can turn OFF the archive step, that is what we're saying | 17:24 |
marler8997 | sure, but then you said it only archived the .git directory | 17:25 |
rburton | what else would you want archived? | 17:25 |
marler8997 | everything except the .git directory | 17:25 |
fray | https://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#var-BB_GENERATE_MIRROR_TARBALLS | 17:25 |
fray | look at that | 17:25 |
rburton | you really want to do what fray and kergoth have told you repeatedly, and turn off the thing you're upset at | 17:26 |
rburton | as it's not on by default | 17:26 |
fray | If you are seeing the system archive them, then someone has turned on BB_GENERATE_MIRROR_TARBALLS in yoru build.. set it to 0 | 17:26 |
fray | it won't do the archiving step | 17:26 |
qschulz | marler8997: haven't read the whople discussion, what about subpath= of the git fetcher? | 17:27 |
marler8997 | subpath is not what we're looking for, it puts the src into a subdir, it doesn't just take a subdir of the SRC | 17:27 |
fray | more up to date link: https://docs.yoctoproject.org/ref-manual/ref-variables.html?highlight=bb_generate_mirror_tarballs#term-BB_GENERATE_MIRROR_TARBALLS | 17:27 |
rburton | the usual system is 1) do_fetch does a bare clones to DL_DIR 2) do_unpack does a local clone to WORKDIR. this way you have a central cache of the git repo that can be fetched again in the future and a local work tree you can delete on rebiuilds | 17:27 |
qschulz | marler8997: no, read again | 17:27 |
marler8997 | > Places the file (or extracts its contents) into the specified subdirectory of WORKDIR | 17:28 |
rburton | the 20 minute download should be *once* as presumably you're sharing DL_DIR between builds. if not, do. | 17:28 |
marler8997 | qschulz, again, not what I was asking about | 17:28 |
qschulz | "subpath": Limits the checkout to a specific subpath of the tree. By default, the whole tree is checked out. | 17:28 |
fray | You were complaing your system was cloning, archiving and then extracting | 17:28 |
fray | we're telling you why and how to turn that off | 17:28 |
marler8997 | rburton, yes, all this goes away after the first build | 17:28 |
*** bhstalel <bhstalel!c15f633e@193.95.99.62> has quit IRC | 17:29 | |
marler8997 | fray yes I see that | 17:29 |
marler8997 | thank you for the suggestion there, I will have to try that out | 17:29 |
qschulz | https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-fetching.html#git-fetcher-git | 17:29 |
marler8997 | but I was confused by you saying that it only archived the .git directory | 17:29 |
fray | the clone is a _bare_ clone.. what in in the .git directory of a 'normal' (not bare) is the same as what is in a abre clone | 17:30 |
fray | I was making an equivalence | 17:30 |
marler8997 | oh qschulz, subpath! | 17:30 |
marler8997 | I thought it was "subdir" | 17:30 |
fray | you won't see a .git directory inside of a bare clone.. | 17:30 |
marler8997 | fray, oh I didn't realize it was a bare clone | 17:30 |
marler8997 | so it does a bare clone, archives that | 17:31 |
fray | and you can speed up the bare clone by using a 'shallow' clone | 17:31 |
fray | I'm not sure where the docs are for the shallow cloning though.. | 17:31 |
fray | I rarely use it | 17:31 |
marler8997 | so then after it extracts it needs to checkout a specific commit from the bare repository? | 17:31 |
fray | yes | 17:31 |
marler8997 | gotcha | 17:31 |
rburton | obviously when you clone another repo that's on disk the .git basically just says 'look there' | 17:32 |
rburton | so the local clone is super fast | 17:32 |
kergoth | bitbake can't currently directly do a bare clone due to the current fetcher design. recipes may specify an exact revision to check out | 17:32 |
kergoth | and you can't clone a depth from a revision, that's a git limitation | 17:32 |
rburton | kergoth: time for fetch3 | 17:33 |
kergoth | so the only thing we support is creating and using shallow git tarballs | 17:33 |
kergoth | i.e. you fetch it from scratch one time, populates a shallow mirror tarball, then you put that on a mirror and use that from then on, and provide it to your coworkers, or whatever | 17:33 |
fray | Ahh didn't realize it was no archive _or_ shallow | 17:33 |
kergoth | technically shallow clone would work with autorev, i guess, but that'd be it | 17:33 |
kergoth | we don't know the precise depth from branch HEAD to the commit we want, so we can't specify it with --depth | 17:33 |
fray | Ya, I've only used shallow with autorev before | 17:33 |
marler8997 | when was this subpath option added to the Git fetcher? | 17:34 |
*** mckoan is now known as mckoan|away | 17:34 | |
marler8997 | actually I'm guessing it won't work either, because it's the SRCREV that's used in the recipe hash I believe | 17:34 |
fray | adb78a15e (Yu Ke 2011-01-19 00:22:13 +0800 464) subdir = ud.parm.get("subpath", "") | 17:34 |
marler8997 | There probably isn't a way to specify a subpath hash | 17:34 |
fray | that was the _latest_ it could have been added, but I'm pretty sure it was there before | 17:34 |
fray | noy uo can not hash the subpath.. the hash is still on the git commit id | 17:34 |
smurray | marler8997: right, subpath won't help with the single SRCREV issue, it just would allow setting up each recipe to only checkout the subdirector(y|ies) it uses | 17:35 |
marler8997 | gotcha, so doesn't solve the problem :( | 17:35 |
marler8997 | would probably be a simple feature to add though | 17:36 |
fray | No the original question you asked it's the whole repository commit... for the second, why does it take so long.. that is what we were talking about | 17:36 |
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC | 17:36 | |
marler8997 | when a subpath is given, don't put SRCREV in the recipe hash, and provide a way to hash everything in the subpath and specify that hash | 17:36 |
*** pharaon2502 <pharaon2502!~manjaro-u@dh207-120-145.xnet.hr> has quit IRC | 17:36 | |
marler8997 | fray yes, two different problems | 17:36 |
marler8997 | there are alot of people talking so I'm sorry if it's confusing who I'm responding to and which problem I'm referring to | 17:37 |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has quit IRC | 17:37 | |
*** tlwoerner <tlwoerner!~tlwoerner@unaffiliated/tlwoerner> has quit IRC | 17:37 | |
*** pharaon2502 <pharaon2502!~manjaro-u@dh207-120-145.xnet.hr> has joined #yocto | 17:37 | |
marler8997 | I was saying that means subpath doesn't solve the first problem | 17:37 |
marler8997 | it could be used to help solve it though, with the extra functionality I specified above | 17:38 |
marler8997 | SRCREV_SUBPATH = "abcdefg..." | 17:39 |
kergoth | srcrev isn't jsut input into the rest of the build, but a specification of precisely what we're fetching. what you're talking about is only the former | 17:41 |
marler8997 | correct | 17:42 |
marler8997 | you would still need SRCREV | 17:42 |
qschulz | well, you could have an SRCREV per recipe and you bump the ones you want when you want. Which means technically you can have an "old" revision for one recipe but if you haven't bumped it, it probably means that the content hasn't changed. | 17:42 |
*** vineela <vineela!~vtummala@134.134.137.75> has joined #yocto | 17:42 | |
marler8997 | qschulz, yes that would also work | 17:42 |
marler8997 | that comes with it's own problem as well though | 17:43 |
qschulz | nothing's free :) | 17:43 |
qschulz | you can see that your initial choice of everything in one git is already costing you :) | 17:43 |
marler8997 | it seems to be the cheapest solution so far | 17:43 |
marler8997 | moving to a "one repo per project" would be quite a high cost | 17:44 |
qschulz | (not saying it's bad per se, it's just that it's not straight-forward in Yocto considering the amount of discussion here today :) ) | 17:44 |
marler8997 | It seems pretty straightforward to me | 17:44 |
marler8997 | the relevant discussion: can you base recipe hash on git subdirectory? No but subpath can limit the file? we could add a SRCREV_SUBPATH... | 17:45 |
qschulz | SRCREV_SUBPATH is irrelevant since you have a recipe per project in your one git repo? | 17:46 |
qschulz | or maybe I missed something (a lot went on :/) | 17:47 |
marler8997 | huh? | 17:47 |
marler8997 | the idea was, if you specify a subpath in your SRC_URI, and SRCREV_SUBPATH, then SRCREV would be omitted from the recipe hash in favor of SRCREV_SUBPATH | 17:47 |
qschulz | I don't get it. You have a git repo with 40 small projects right? | 17:48 |
marler8997 | yes | 17:48 |
qschulz | You have 40 recipes, one for each project? | 17:48 |
marler8997 | yes | 17:48 |
qschulz | then one recipe has SRC_URI with subpath, and SRCREV | 17:48 |
qschulz | that's it? | 17:48 |
fray | qschulz sounds like one SCM with a bunch of related, but sepeate projects.. it's not unusual in companies I've worked with.. | 17:49 |
qschulz | and SRCREV is *NOT* in common with all recipes | 17:49 |
marler8997 | we don't use subpath at all right now, but the idea was they could all use subpath | 17:49 |
marler8997 | it IS common to all recipes | 17:49 |
marler8997 | we put the SRCREV in a class | 17:49 |
qschulz | marler8997: then don't | 17:49 |
marler8997 | that they all inherit from | 17:49 |
marler8997 | again, having a different SRCREV in every recipe comes with it's own problems | 17:49 |
marler8997 | for example. for projects that depend on each other, they can get out of sync | 17:49 |
qschulz | that's maintenance | 17:50 |
qschulz | but yeah | 17:50 |
qschulz | You'll have to make compromise somewhere | 17:50 |
marler8997 | not really helpful advice though is it? | 17:50 |
qschulz | be it that you add support for the SRCREC_SUBPATH you're talking about or not | 17:50 |
marler8997 | what I'm asking for isn't impossible, nor difficult, it just sounds like it hasn't been implemented | 17:51 |
kergoth | If it hasn't been implemented, it's because it's not a common use case, or no one with the resources has cared enough to make the change. If that's changed now, by all means submit a patch | 17:51 |
fray | If you can find native git commands to do it, then it's possible.. otherwise it really is a custom request.. | 17:51 |
qschulz | marler8997: come on. We gave you multiple ways to do it. You had knowledgeable people on it. We can't decide for you, you test. You see if it works for you, if not, try another implementation or develop a new one | 17:51 |
marler8997 | kergeroth yes I agree | 17:51 |
marler8997 | this is clearly not as common of a use case as one project per repository | 17:52 |
kergoth | but i doubt anyone else will do it for you, lacking the impetus that's driving you now | 17:52 |
marler8997 | not sure what your point is though | 17:52 |
marler8997 | lol, I never said anyone would | 17:52 |
marler8997 | who are you talking to? | 17:52 |
marler8997 | sounds like you're talking to some weird alternate reality version of me | 17:53 |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto | 17:53 | |
kergoth | Uh, weirdly defensive there. I didn't claim you said someone would, only clarified that if you wanted it done, you'd need to do it | 17:53 |
marler8997 | qshulz, what is your point? You asked for clarification and I provided it, and now you're talking to me as if I'm not listening to the adivce people have given | 17:54 |
marler8997 | "come on, we gave you multiple ways to do it" | 17:54 |
qschulz | you exhausted my patience for today, I'll let you with other people. Good luck | 17:55 |
marler8997 | qschulz, you are the one asking questions, you can stop asking them at any time | 17:56 |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has quit IRC | 17:58 | |
*** dleppich <dleppich!~Thunderbi@p5098be52.dip0.t-ipconnect.de> has quit IRC | 17:59 | |
*** onkelpit <onkelpit!5d8510a6@dynamic-093-133-016-166.93.133.pool.telefonica.de> has quit IRC | 18:01 | |
*** RobertBerger <RobertBerger!~rber@128.90.148.128> has quit IRC | 18:09 | |
*** tlwoerner <tlwoerner!~tlwoerner@unaffiliated/tlwoerner> has joined #yocto | 18:09 | |
*** onkelpit <onkelpit!~onkelpit@dynamic-093-133-016-166.93.133.pool.telefonica.de> has joined #yocto | 18:10 | |
*** learning <learning!bb14930d@187.20.147.13> has joined #yocto | 18:11 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-zlurlwjkoisvsmab> has quit IRC | 18:11 | |
*** kaspter <kaspter!~Instantbi@183.192.136.178> has quit IRC | 18:17 | |
*** kaspter <kaspter!~Instantbi@2409:8a1e:911b:1000:d165:4a24:ce2b:3f45> has joined #yocto | 18:18 | |
*** Kyubi <Kyubi!~Kyubi@149.199.62.131> has quit IRC | 18:21 | |
codyps | Hi folks, I'm seeing a build failure of `bitbake -cpopulate_sdk my-image` where my-image includes util-linux, causing the sdk to include util-linux-doc, resulting in the pkg_postinst_append_${MAN_PKG} from manpages.bbclass running, which tries to `chown man:man` but fails because that user/group doesn't exist (resulting in the do_populate_sdk failing). | 18:25 |
codyps | Any advise for how to fix this properly upstream? I'm probably going to workaround this by trying to disable the manpages in the sdk. | 18:25 |
codyps | I'm considering if a variable to allow controlling the user/group used for man pages makes sense here. Or doing some specialization of manpages.bbclass for nativesdk packages. | 18:27 |
codyps | (well, not actually nativesdk packages. `util-linux-doc` is a target package) | 18:28 |
*** Kyubi <Kyubi!~Kyubi@149.199.62.131> has joined #yocto | 18:30 | |
*** dev1990 <dev1990!~dev@178-36-238-233.adsl.inetia.pl> has quit IRC | 18:30 | |
fray | target software is installed using pseudo, which uses it's own passwd/group file. Verify that the base-passwd on your system has man user and group in it | 18:31 |
fray | (check etc/passwd and etc/group inside of the target roofs) | 18:32 |
stacktrust | Does the Yocto autobuilder share a public sstate cache for dunfell and qemuarm64 machine? | 18:36 |
rburton | yes | 18:42 |
*** RobertBerger <RobertBerger!~rber@128.90.148.10> has joined #yocto | 18:42 | |
rburton | its mentioned in the sample local.conf iirc | 18:42 |
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-xnbsyfusougticbk> has quit IRC | 18:45 | |
codyps | fray: where would I look for the sysroot with the passwd/group file used for TOOLCHAIN_TARGET_TASK installation? looking at `tmp/work/$MACHINE-$TARGET_VENDOR-linux-gnueabi/my-image/1.0-r0/sdk/image` only shows the stuff in the sdk (which doesn't include any `/etc/*` files, it's just all the sdk packages installed in `/opt`). | 18:46 |
stacktrust | @rburton thanks | 18:49 |
*** learning <learning!bb14930d@187.20.147.13> has quit IRC | 18:49 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-mmpquempibxzzfvh> has joined #yocto | 18:49 | |
codyps | ah, one can drill down to the sysroot inside that. (`tmp/work/$MACHINE-$TARGET_VENDOR-linux-gnueabi/my-image/1.0-r0/sdk/image/opt/my-distro/sysroots/armv7vet2hf-neon-$TARGET_VENDOR-linux-gnueabi`) that `passwd` does include a `man` user, making the error more questionable. | 18:49 |
codyps | that `etc/group` also has a man group. | 18:50 |
codyps | Is there something in the log.do_populate_sdk which would indicate which sysroot exactly pseudo is using here? | 18:56 |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 19:05 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto | 19:07 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 19:13 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 19:14 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 19:14 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 19:14 | |
*** kaspter <kaspter!~Instantbi@2409:8a1e:911b:1000:d165:4a24:ce2b:3f45> has quit IRC | 19:19 | |
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 19:20 | |
moto-timo | stacktrust: but you need to change the version to point to it... I think it still says 2.5 in the local.conf.sample | 19:27 |
*** yann <yann!~yann@88.120.44.86> has quit IRC | 19:28 | |
*** xtopher <xtopher!~xtopher@2600:380:445e:2f5b:a192:9459:4a40:ed16> has joined #yocto | 19:34 | |
xtopher | am running a local dunfell build to generate a xen-image-minimal image with the qemuarm64 machine and I've got the SSTATE_MIRRORS pointed at: http://sstate.yoctoproject.org/3.1/PATH;downloadfilename=PATH but don't seem to be seeing a lot of cache hits / acceleration | 19:37 |
xtopher | would switching from rpm to ipk be expected to change the hit rate a lot? | 19:37 |
xtopher | maybe the version should be 3.1.4 in the url? | 19:39 |
*** alessioigor <alessioigor!~alessioig@93-47-228-8.ip115.fastwebnet.it> has joined #yocto | 19:40 | |
*** gonkulator <gonkulator!~brandon@75.71.150.20> has quit IRC | 19:42 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has quit IRC | 19:47 | |
*** gonkulator <gonkulator!~brandon@75.71.150.20> has joined #yocto | 19:50 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 19:51 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 19:53 | |
*** paulg <paulg!~paulg@104-195-159-54.cpe.teksavvy.com> has quit IRC | 19:53 | |
*** paulg <paulg!~paulg@104-195-159-54.cpe.teksavvy.com> has joined #yocto | 19:54 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 19:54 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 19:54 | |
xtopher | It looks like the autobuilder has quite a few more layers enabled than my minimal build, so maybe not much commonality once those are present. | 19:54 |
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:4f7:596d:bf31:3950:5bda> has joined #yocto | 19:56 | |
*** dagmcr <dagmcr!sid323878@gateway/web/irccloud.com/x-hfbzuapftzgnhfcr> has quit IRC | 20:03 | |
*** awafaa <awafaa!sid716@gateway/web/irccloud.com/x-hrdyaofokjxxxtnh> has quit IRC | 20:03 | |
*** rsalveti <rsalveti!uid117878@gateway/web/irccloud.com/x-dflvclkpswebrcdz> has quit IRC | 20:03 | |
*** rsalveti <rsalveti!uid117878@gateway/web/irccloud.com/x-dxipazzeiklfdyjd> has joined #yocto | 20:04 | |
*** dagmcr <dagmcr!sid323878@gateway/web/irccloud.com/x-zfgxhflsdgwtubcs> has joined #yocto | 20:04 | |
*** awafaa <awafaa!sid716@gateway/web/irccloud.com/x-ajhhsrcspisypfmg> has joined #yocto | 20:04 | |
codyps | Welp, removing `manpages` from PACKAGECONFIG fixes the broken populate_sdk util-linux-doc due to `chown man:man`: `PACKAGECONFIG_remove_pn-util-linux = "manpages"`. I looked a bit further on the PSEUDO stuff, and found that PSEUDO_SYSROOT points to the sysroot pseudo is using. The passwd/group in sysroot does not have a man user. It's pretty minimal: | 20:05 |
codyps | https://gist.github.com/4a13dd5729786eb2b7479c13ba1b4216 | 20:05 |
codyps | I suspect the issue here is down to the packages being installed in the sdk modifying the etc/{passwd,group} in the sdk sysroot, but not the pseudo sysroot, resulting in the etc/{passwd,group} in the pseudo sysroot not having the required `man` user/group. Though it doesn't seem to make much sense to have `etc/{passwd,group}` in the sdk sysroot at all (not clear what would ever use them). | 20:09 |
*** pharaon2502 <pharaon2502!~manjaro-u@dh207-120-145.xnet.hr> has quit IRC | 20:12 | |
*** alessioigor <alessioigor!~alessioig@93-47-228-8.ip115.fastwebnet.it> has quit IRC | 20:20 | |
*** Kyubi <Kyubi!~Kyubi@149.199.62.131> has quit IRC | 20:21 | |
zeddii | RP: first pass with my 5.10-everything builds looks good. Hopefully I'll have it uprev'd early this cycle, and can focus on other features that I normally just kick down the road. | 20:24 |
*** Kyubi <Kyubi!~Kyubi@149.199.62.131> has joined #yocto | 20:25 | |
*** bluelightning_ is now known as bluelightning | 20:36 | |
smurray | zeddii: heh, 5.10.1? ;) | 20:37 |
zeddii | yup | 20:38 |
zeddii | as of 10 minutes ago, its still rebuilding | 20:38 |
zeddii | but if greg busted us in .1, that's a shin-kicking | 20:38 |
zeddii | a .1 half an hour after the release is a brown paper bag fix | 20:39 |
paulbarker | I saw that before | 20:41 |
paulbarker | zeddii: https://twitter.com/kernellogger/status/1338379381392216065 | 20:41 |
paulbarker | btrfs raid6 mounting issue I believe | 20:42 |
zeddii | ahah | 20:42 |
smurray | yeah, definitely a brown paper bag bug | 20:42 |
paulbarker | TBH anyone using btrfs raid5/6 is a daredevil anyway | 20:42 |
zeddii | truth! which is why I'd never, ever see that issue. | 20:43 |
*** stzsch <stzsch!~stzsch@187.44.81.18> has joined #yocto | 20:46 | |
*** onkelpit <onkelpit!~onkelpit@dynamic-093-133-016-166.93.133.pool.telefonica.de> has quit IRC | 20:47 | |
*** bobo <bobo!~bobo@customer-145-14-101-3.stosn.net> has joined #yocto | 20:50 | |
*** gonkulator <gonkulator!~brandon@75.71.150.20> has joined #yocto | 20:50 | |
*** habing <habing!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has joined #yocto | 20:50 | |
*** xtopher <xtopher!~xtopher@2600:380:445e:2f5b:a192:9459:4a40:ed16> has quit IRC | 20:57 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto | 21:11 | |
*** habing <habing!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has quit IRC | 21:22 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 21:37 | |
RP | zeddii: it was really the previous release which was why it worked so smoothly but they're fixing in .1? :) | 21:40 |
RP | zeddii: seriously, that sounds good to be able to look at other things for a change | 21:40 |
moto-timo | +1 | 21:45 |
*** Shikadi` <Shikadi`!~Shikadi@135.30.27.136.in-addr.arpa> has joined #yocto | 21:46 | |
*** xtopher <xtopher!~xtopher@2600:380:445e:2f5b:a192:9459:4a40:ed16> has joined #yocto | 21:49 | |
*** Konsgnx1 <Konsgnx1!~Konsgnx3@66-109-34-138.tvc-ip.com> has joined #yocto | 21:50 | |
*** Konsgn <Konsgn!~Konsgnx3@unafiliated/joyseph> has quit IRC | 21:50 | |
xtopher | @zeddii: I think the 5.10 yocto-kernel-dev branch for standard/bcm-2xxx-rpi branch is broken on the Raspberry Pi 4 at the moment, with what looks like a rough merge in the vc4 graphics driver | 21:50 |
*** vineela <vineela!~vtummala@134.134.137.75> has quit IRC | 21:51 | |
xtopher | 5.9 seems to boot ok, and in switching branch I found that I need to get you an update for the dynamic-layers raspberry pi logic where KBRANCH is set for the raspberrypi4-64 | 21:52 |
*** vineela <vineela!vtummala@nat/intel/x-chwcxnjhaskclxaf> has joined #yocto | 22:00 | |
*** paulg <paulg!~paulg@104-195-159-54.cpe.teksavvy.com> has quit IRC | 22:01 | |
*** paulg <paulg!~paulg@104-195-159-54.cpe.teksavvy.com> has joined #yocto | 22:01 | |
*** grumble <grumble!~Thunderbi@freenode/staff/grumble> has quit IRC | 22:03 | |
*** xtopher <xtopher!~xtopher@2600:380:445e:2f5b:a192:9459:4a40:ed16> has quit IRC | 22:04 | |
*** grumble <grumble!~Thunderbi@freenode/staff/grumble> has joined #yocto | 22:12 | |
*** Kyubi <Kyubi!~Kyubi@149.199.62.131> has quit IRC | 22:21 | |
*** Kyubi <Kyubi!~Kyubi@149.199.62.131> has joined #yocto | 22:34 | |
*** lexano <lexano!~lexano@cpeb03956d8c2f4-cm98524a70e35e.cpe.net.cable.rogers.com> has quit IRC | 22:41 | |
*** lexano <lexano!~lexano@cpeb03956d8c2f4-cm98524a70e35e.cpe.net.cable.rogers.com> has joined #yocto | 22:43 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 22:52 | |
mischief | lets say i have N machines. should they be in N different layers or one layer? why? | 22:57 |
*** paulg <paulg!~paulg@104-195-159-54.cpe.teksavvy.com> has quit IRC | 23:12 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 23:14 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 23:14 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has quit IRC | 23:15 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 23:18 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-mmpquempibxzzfvh> has quit IRC | 23:19 | |
*** paulg <paulg!~paulg@104-195-159-54.cpe.teksavvy.com> has joined #yocto | 23:25 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 23:25 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 23:29 | |
*** wz <wz!~wojteg@89-64-68-83.dynamic.chello.pl> has joined #yocto | 23:34 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 23:34 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 23:35 | |
*** agust <agust!~agust@p5483356f.dip0.t-ipconnect.de> has quit IRC | 23:37 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 23:37 | |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 23:38 | |
*** radsquirrel <radsquirrel!~radsquirr@173.167.31.197> has quit IRC | 23:40 | |
*** radsquirrel <radsquirrel!~radsquirr@2603:3015:e15:5bf2:d0b3:d9ff:fede:b022> has joined #yocto | 23:40 | |
codyps | hmmm... so I just annotated the `pkg_postinst_append_${MAN_PKG}` in manpages.bbclass to dump the passwd/group files before trying to chown. They are _definitely_ my host system's passwd/group. Does pseudo not redirect reads of those and instead fiddle with getpwnam/getgrent ? While I've worked around the broken man page install in populate_sdk by disabling man pages, I would like to fix this | 23:41 |
codyps | correctly. | 23:41 |
*** gendevbot_ <gendevbot_!~devbot@176.235.187.234> has quit IRC | 23:44 | |
*** gendevbot <gendevbot!~devbot@176.235.187.234> has joined #yocto | 23:45 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has joined #yocto | 23:53 | |
*** kiwi_29 <kiwi_29!~kiwi_29@c-73-231-211-214.hsd1.ca.comcast.net> has quit IRC | 23:58 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!