Monday, 2020-12-14

*** hpsy1 <hpsy1!~hpsy@> has joined #yocto00:06
*** hpsy <hpsy!~hpsy@> has quit IRC00:08
*** goliath <goliath!> has quit IRC01:09
*** gpanders <gpanders!> has quit IRC01:16
*** gpanders <gpanders!> has joined #yocto01:17
zeddiimoto-timo: yah. but still hard to find. I just built the exact same hash as the working k3s reference from rancher, crashloop.01:24
zeddiiso that means it is something in our go compiler or config.01:24
*** pung_ <pung_!~BobPungar@> has joined #yocto01:29
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC01:31
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:54
*** Kyubi <Kyubi!~Kyubi@2601:640:103:f36e:7d19:9c46:eae8:7560> has joined #yocto01:54
*** bps3 <bps3!~bps@> has joined #yocto01:58
*** pung_ <pung_!~BobPungar@> has quit IRC02:07
*** pung_ <pung_!~BobPungar@> has joined #yocto02:07
*** Kyubi <Kyubi!~Kyubi@2601:640:103:f36e:7d19:9c46:eae8:7560> has quit IRC02:25
moto-timozeddii: I am still trying to figure out why k9s bitches about protobuf and other random fs perms bullshyte02:38
*** gpanders <gpanders!> has quit IRC02:39
*** gpanders <gpanders!> has joined #yocto02:39
*** sakoman <sakoman!> has quit IRC02:42
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto02:43
*** bps3 <bps3!~bps@> has quit IRC03:08
*** bps <bps!~bps@> has joined #yocto03:14
zeddiihah. sounds painful.03:14
zeddiiI'm spelunking in the k3s build scripts to see if the recipe is missing something .. nothing obvious so far.03:15
*** roussinm <roussinm!> has quit IRC03:28
*** ahadi <ahadi!~ahadi@> has quit IRC03:46
*** pung_ <pung_!~BobPungar@> has quit IRC03:47
*** ahadi <ahadi!> has joined #yocto03:47
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto03:47
*** kaspter <kaspter!~Instantbi@> has quit IRC03:52
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:52
*** Kyubi <Kyubi!~Kyubi@> has quit IRC03:54
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto03:55
moto-timozeddii: trust me, I stared at it for a while and found nothing04:21
zeddiiI'm trying to find exactly how the reference one is built. ours is simply garbage.04:21
zeddiidrop in the k3s binary, everything else the same. magic.04:21
zeddiiI'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-timoI know. I fuckng hate that voodooo bullshit04:22
zeddiithe 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
zeddiiI loathe the way go builds04:23
moto-timo#2020 #dumpsterfire04:23
moto-timogo can just go04:23
moto-timolike why does k0s build gloriously the first time and then BITCH the xecond time?04:23
moto-timof' you04:23
zeddiiyup. 11pm on a sunday, I'm moving off to call it a day. will work on this during the day tomorrow.04:24
moto-timoI successfully built kicad nightly on a raspberrypi40004:24
moto-timoI have spoken04:24
moto-timoI thought it was Monday04:24
moto-timoFUck me04:25
zeddiihahah. blame your sabattical!04:25
* moto-timo has lost his filter... forgive me it is sabbatical and #202004:25
zeddiiI'm going to drool over some netflix and maybe get inspired to try another tactic tomorrow!04:25
zeddiicatch you later!04:25
moto-timog'night zeddii04:25
moto-timomay the force be with you04:25
moto-timoas always, ping me with random crap04:26
*** pung_ <pung_!~BobPungar@> has joined #yocto04:45
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC04:45
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto04:50
*** pung_ <pung_!~BobPungar@> has quit IRC04:52
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto05:12
*** dreyna <dreyna!> has joined #yocto05:20
*** w00die <w00die!~w00die@> has quit IRC05:22
*** w00die <w00die!~w00die@> has joined #yocto05:24
*** Ad0 <Ad0!~Ad0@> has quit IRC05:27
*** Ad0 <Ad0!~Ad0@> has joined #yocto05:32
*** kaspter <kaspter!~Instantbi@> has quit IRC05:50
*** kaspter <kaspter!~Instantbi@> has joined #yocto05:51
*** Kyubi <Kyubi!~Kyubi@> has quit IRC05:54
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto05:55
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto05:56
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC05:59
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC06:01
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has joined #yocto06:02
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto06:10
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC06:13
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto06:15
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC06:16
*** jobroe <jobroe!> has joined #yocto06:19
*** hpsy1 <hpsy1!~hpsy@> has quit IRC06:19
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto06:27
*** davidinux <davidinux!~davidinux@> has joined #yocto06:28
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC06:30
*** AndersD <AndersD!> has joined #yocto06:38
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto06:48
*** jleightcap1 <jleightcap1!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has quit IRC06:50
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC06:51
*** jleightcap1 <jleightcap1!> has joined #yocto06:52
*** Shikadi` <Shikadi`!~Shikadi@> has quit IRC06:59
zygahello :)07:00
*** zyga <zyga!> has quit IRC07:00
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto07:00
*** TobSnyder <TobSnyder!> has quit IRC07:07
*** camus <camus!~Instantbi@> has joined #yocto07:10
*** kaspter <kaspter!~Instantbi@> has quit IRC07:11
*** camus is now known as kaspter07:11
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto07:12
*** minimaxwell <minimaxwell!> has joined #yocto07:12
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC07:15
*** RobertBerger <RobertBerger!> has joined #yocto07:16
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has joined #yocto07:18
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC07:21
*** amitk <amitk!~amit@unaffiliated/amitk> has joined #yocto07:22
*** amitk_ <amitk_!~amit@unaffiliated/amitk> has quit IRC07:23
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:23
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:40
*** frsc <frsc!> has joined #yocto07:41
*** goliath <goliath!> has joined #yocto07:41
*** frwol <frwol!> has joined #yocto07:44
*** Kyubi <Kyubi!~Kyubi@> has quit IRC07:44
LetoThe2ndyo dudX07:48
*** creich <creich!> has quit IRC07:49
*** creich <creich!> has joined #yocto07:50
*** beneth <beneth!> has joined #yocto07:56
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto07:57
*** fl0v0 <fl0v0!~fvo@> has joined #yocto07:57
*** kpo_ <kpo_!> has quit IRC08:08
*** kpo_ <kpo_!> has joined #yocto08:09
*** tnovotny <tnovotny!> has joined #yocto08:12
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto08:13
*** OnkelUlla <OnkelUlla!> has quit IRC08:14
*** armpit <armpit!~armpit@2601:202:4180:a5c0:c584:dc9f:dcf0:9e06> has quit IRC08:15
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has quit IRC08:15
*** stefan-schmidt[m <stefan-schmidt[m!stefan-sch@gateway/shell/> has quit IRC08:16
*** OnkelUlla <OnkelUlla!> has joined #yocto08:16
*** stefan-schmidt[m <stefan-schmidt[m!stefan-sch@gateway/shell/> has joined #yocto08:16
*** jleightcap1 <jleightcap1!> has quit IRC08:16
*** jobroe <jobroe!> has quit IRC08:16
*** MiskaX <MiskaX!> has quit IRC08:16
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC08:16
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has quit IRC08:16
*** ssajal <ssajal!> has quit IRC08:16
*** gonkulator <gonkulator!~brandon@> has quit IRC08:16
*** alinucs <alinucs!> has quit IRC08:16
*** cengiz_io <cengiz_io!~cengiz_io@> has quit IRC08:16
*** dirbaio <dirbaio!> has quit IRC08:16
*** nslu2-log__ <nslu2-log__!> has quit IRC08:16
*** mrpelotazo <mrpelotazo!> has quit IRC08:16
*** iokill <iokill!> has quit IRC08:16
*** armpit <armpit!~armpit@2601:202:4180:a5c0:517b:4767:4af3:9059> has joined #yocto08:16
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has joined #yocto08:17
*** oberstet <oberstet!~oberstet@> has joined #yocto08:17
*** ahadi <ahadi!> has quit IRC08:19
*** ahadi <ahadi!> has joined #yocto08:21
*** jleightcap1 <jleightcap1!> has joined #yocto08:22
*** jobroe <jobroe!> has joined #yocto08:22
*** MiskaX <MiskaX!> has joined #yocto08:22
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto08:22
*** vquicksilver <vquicksilver!~nobody@gentoo/contributor/vquicksilver> has joined #yocto08:22
*** ssajal <ssajal!> has joined #yocto08:22
*** gonkulator <gonkulator!~brandon@> has joined #yocto08:22
*** alinucs <alinucs!> has joined #yocto08:22
*** cengiz_io <cengiz_io!~cengiz_io@> has joined #yocto08:22
*** dirbaio <dirbaio!> has joined #yocto08:22
*** nslu2-log__ <nslu2-log__!> has joined #yocto08:22
*** mrpelotazo <mrpelotazo!> has joined #yocto08:22
*** iokill <iokill!> has joined #yocto08:22
*** dreyna <dreyna!> has quit IRC08:22
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:23
*** mckoan|away is now known as mckoan08:23
mckoangood morning08:23
*** wz <wz!> has joined #yocto08:24
*** pharaon2502 <pharaon2502!> has joined #yocto08:30
*** jleightcap1 <jleightcap1!> has quit IRC08:30
*** jleightcap1 <jleightcap1!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has joined #yocto08:32
*** mrpelotazo <mrpelotazo!> has quit IRC08:33
*** mrpelotazo <mrpelotazo!> has joined #yocto08:33
*** lukma <lukma!> has quit IRC08:34
*** agust <agust!> has joined #yocto08:42
*** jleightcap1 <jleightcap1!~jleightca@2601:98a:300:49c:8f48:3b40:afb7:26ee> has quit IRC08:50
*** lukma <lukma!> has joined #yocto08:52
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:5178:619c:fc92:5a85> has joined #yocto09:10
qschulzhello there09:11
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:5178:619c:fc92:5a85> has quit IRC09:13
LetoThe2ndyo qschulz09:19
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:26
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:29
*** manuel__ <manuel__!> has joined #yocto09:35
*** leon-anavi <leon-anavi!~Leon@> has quit IRC09:48
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:48
rob_whi there .. i got a issue with a simple makefile situation ..  i cannot get a correct which compiles my objects in parallel and not in a serial way09:54
rob_wsome trys fail as the toolchain then misses paths , some fail because my lack of autotool knowledge09:54
*** Bunio_FH <Bunio_FH!> has quit IRC09:58
LetoThe2ndrob_w: any particular requirement nailing you down on autotools then, if you're already having problems with it?09:59
*** kaspter <kaspter!~Instantbi@> has quit IRC10:00
*** kaspter <kaspter!~Instantbi@> has joined #yocto10:00
rob_witts a understanding issue i think .. .i got a where i place foo_SOURCES = 1.c 2.c 3.c etc then foo_LDADD and bin_PROGRAMS = foo10:01
rob_wbut i want that 1.c 2.c 3.c etc are compile via make -j X  .. in parallel so to speak10:01
rob_wbut it compiles one after the other10:01
rob_wso i understand that i would need to specify the 1.o 2.o 3.o as seperate targets ?10:02
LetoThe2ndmy knowledge there is pretty limited too, but i dont think that this is the case.10:04
*** Bunio_FH <Bunio_FH!> has joined #yocto10:12
*** bhstalel <bhstalel!c15f633e@> has joined #yocto10:20
bhstalelHi, I don't want to interrupt an active conversation but I have an urgent question:10:21
bhstalelI have an LCD display10:21
bhstalelWhere to put the video parameter ? in uboot devicetree bootargs ?10:22
bhstalelOr somewhere in the kernel ?10:22
bhstalelThe LCD interface in MIPI DSI10:23
qschulzvideo parameters?10:25
mckoanbhstalel: machine name ?10:28
bhstalelI'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 it10:29
mckoanbhstalel: in u-boot, it is the kernel command line10:33
qschulzput it into the bootargs u-boot env variable10:33
*** LocutusOfBorg <LocutusOfBorg!~locutusof@ubuntu/member/locutusofborg> has quit IRC10:34
bhstalelOkay , I'll look into it, thanks all :))))10:35
rob_wwell my problem just resolved .. i realized my code would not gain compile speed even with parallel make -j .. thx anyway10:40
rob_w90% of my time is coming from one particular .c file .. so until i split this up it is what it is10:41
*** LocutusOfBorg <LocutusOfBorg!> has joined #yocto10:47
*** LocutusOfBorg <LocutusOfBorg!~locutusof@ubuntu/member/locutusofborg> has joined #yocto10:47
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC10:49
*** dleppich <dleppich!> has joined #yocto10:53
*** dleppich <dleppich!> has joined #yocto11:07
*** leon-anavi <leon-anavi!~Leon@> has quit IRC11:13
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto11:13
*** chris456 <chris456!> has joined #yocto11:22
chris456i want to compile a go program and i got an erro:
chris456do i have to add a specific "go"-layer or should it work out of the box?11:32
otavioRP: can you take a look at "Strange segfault on native Go binaries" on ml?11:32
otaviochris456: on recent Yocto Project releases, we have Go support on OE-Core11:33
RPotavio: I had seen it. Are you using sstate generated by the nixos system on the ubuntu one?11:33
RPotavio: I'd suspect some kind of patchelf problem, particularly as nixos uses patchelf extensively itself11:34
chris456octavio:  <- this one?11:36
otavioRP: no, I did it all inside the docker11:36
otavioRP: I did not run it inside the nixos. As I mentioned to khem I am using a Docker container with Ubuntu 20.0411:37
*** habing <habing!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has joined #yocto11:48
otavioRP: I believe it is reproducible there.11:48
*** zandrey <zandrey!~zandrey@> has joined #yocto11:56
RPotavio: at that point you probably have to try and see if patchelf is breaking the binary...11:56
otavioRP: can you tell me where to look?11:59
otavioI can check, for sure11:59
RPotavio: have a look at the code in uninative.bbclass. You'd want to try the binary before and after the patchelf --set-interpreter call12:03
RPotavio: 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
RPotavio: there are also chrpath calls from chrpath.bbclass which may edit the binary so those could also be a potential cause12:05
*** tgoodwin <tgoodwin!> has joined #yocto12:28
*** kaspter <kaspter!~Instantbi@> has quit IRC12:43
*** kaspter <kaspter!~Instantbi@> has joined #yocto12:43
*** leon-anavi <leon-anavi!~Leon@> has quit IRC13:04
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto13:04
*** marc1 <marc1!~marc@> has quit IRC13:06
*** leon-anavi <leon-anavi!~Leon@> has quit IRC13:14
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto13:14
*** bps <bps!~bps@> has quit IRC13:21
*** hpsy <hpsy!~hpsy@> has joined #yocto13:28
RPrburton: I think the syslinux changes aren't happy:
RPI'll reply on list so aesh can see it13:37
*** hpsy <hpsy!~hpsy@> has quit IRC13:39
*** kaspter <kaspter!~Instantbi@> has quit IRC13:42
rburtonisohybrid: not found13:47
rburtonwell at least it wasn't something i did to syslinux directly13:47
RPrburton: doesn't look too serious to fix13:54
rburtonyou say that13:54
rburtonthis is syslinux13:54
*** sakoman <sakoman!> has joined #yocto13:54
RPrburton: I'm trying to be positive ;-)13:55
RPrburton: 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 IRC13:58
rburtonkicking a selftest run to verify the patches before submitting14:03
*** PaowZ <PaowZ!~vince@2a01:e0a:144:d020:6d94:8140:daf2:8421> has joined #yocto14:09
*** luneff <luneff!~yury@> has joined #yocto14:20
*** marc1 <marc1!> has joined #yocto14:25
*** ericch <ericch!> has joined #yocto14:26
*** ecdhe_ is now known as ecdhe14:31
*** Bunio_FH <Bunio_FH!> has quit IRC14:32
*** vmeson <vmeson!> has joined #yocto14:42
tardypHello. 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
tardypeach bbappend would add the proper extended attribute to the installed files14:46
qschulzdon't know about smack but that sounds like a good use for something handled on the distro level?14:50
*** Bunio_FH <Bunio_FH!> has joined #yocto14:50
rburtontardyp: there's a worked example of using smack in tizen/iot-dev-kit if you dig out the old repos14:51
rburtonnot sure of anyone using it since then though14:51
RPtardyp: are the bbappend files similar and boilerplate? If so there are other ways you could inject into all recipes14:52
RPif they're custom to each recipe that gets harder14:52
tardypwe need to split our fs into a dozen  domain, and then inject the right xattr to each file according to their domain14:53
rburtonare there any package managers that successfully package up extended attributes?14:54
tardypI saw an old email saying it wasn't obvious14:54
RPtardyp: there are hooks during packaging for example where you could hook in such a generic processing function14:56
smurrayAGL uses postinst to do the labeling on first boot14:57
tardypI saw something like this indeed. not sure if this is really scalable15:00
*** roussinm <roussinm!> has joined #yocto15:00
rburtonnot sure how AGL does it, but a class you can globally inherit to write a postinst would be fairly simple to write15:00
tardypyes, 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
smurrayrburton: 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@> has quit IRC15:02
rburtonsmurray: i've done incredibly well by not asking anything about AGL so far ;)15:02
smurrayrburton: heh15:02
smurraytardyp: 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 it15:04
tardypmkfs.ext4 is not capable of creating xattr at the beginning, right?15:05
tardypI mean at the image creation time15:06
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:13
*** stephano <stephano!~stephano@> has joined #yocto15:17
*** tnovotny <tnovotny!> has quit IRC15:17
smurraytardyp: not that I'm aware of15:25
*** kaspter <kaspter!~Instantbi@2409:8a1e:911b:1000:54:c66b:ba18:66cc> has joined #yocto15:29
dl9pfhmm ... mkfs.ext4 -O  flag ?  maybe ?15:31
*** Konsgn <Konsgn!> has joined #yocto15:34
*** Konsgn <Konsgn!~Konsgnx3@unafiliated/joyseph> has joined #yocto15:34
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has quit IRC15:43
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has joined #yocto15:43
*** OnkelUlla <OnkelUlla!> has quit IRC15:44
smurraydl9pf: that's for filesystem features AFAIK?15:46
*** OnkelUlla <OnkelUlla!> has joined #yocto15:47
smurrayI 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
smurrayand the easiest thing that comes to mind is loopback mounting, which seems potentially problematic wrt doing it as non-root15:52
*** zandrey <zandrey!~zandrey@> has quit IRC15:52
*** dreyna <dreyna!> has joined #yocto15:53
dl9pfright, right.16:01
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto16:02
tardypindeed. qemu is hard to run in the CI, because you need kvm access for best perf. Maybe we can look at user mode linux16:04
tardypboth options looks quite complicated for the usecase :-/16:04
smurraytardyp: right, there's a reason why most distros end up doing it at boot16:13
smurraytardyp: 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 usecases16:15
*** jobroe <jobroe!> has quit IRC16:20
*** Kyubi <Kyubi!~Kyubi@2601:640:109:58ea:b15c:c47f:eaa3:f5c4> has joined #yocto16:21
*** Kyubi <Kyubi!~Kyubi@2601:640:109:58ea:b15c:c47f:eaa3:f5c4> has quit IRC16:27
*** AndersD <AndersD!> has quit IRC16:29
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto16:31
*** pit82 <pit82!> has joined #yocto16:38
*** pit82 is now known as onkelpit16:39
*** RobertBerger <RobertBerger!> has quit IRC16:44
*** RobertBerger <RobertBerger!~rber@> has joined #yocto16:45
*** frsc <frsc!> has quit IRC16:49
*** kaspter <kaspter!~Instantbi@2409:8a1e:911b:1000:54:c66b:ba18:66cc> has quit IRC16:54
*** camus <camus!~Instantbi@> has joined #yocto16:54
armpitzeddii, really16:54
*** camus is now known as kaspter16:56
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC16:59
*** marler8997 <marler8997!> has joined #yocto17:02
marler8997Is 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!> has quit IRC17:03
*** beneth <beneth!> has left #yocto17:03
*** fl0v0 <fl0v0!~fvo@> has quit IRC17:04
qschulzmarler8997: you can give a directory to SRC_URI yes17:05
qschulzfile://dir or file://dir/ will work17:05
qschulzeverything in it will be taken17:05
qschulzI repeat, DO NOT USE PATTERNS (globs, regexp, whatever) it does NOT work17:06
marler8997we have a repository where we keep around 40 small projects17:06
marler8997we put the SRC_URI for this repository in a class so all the recipes just inherit from this class and we only update one location17:06
frayyou 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
marler8997but that means when any one project changes, the hash changes for all the projects17:07
frayyup, 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
marler8997I 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 IRC17:07
marler8997first, I haven't established yet whether yocto support this or not17:07
frayYocto Project CAN share a single SCM across recipes.. easily.. we do it all the time17:08
marler8997yes I know, that's what we're doing17:08
frayHowever, it CAN'T distinguish one portion of a checkout from another.. it CAN distinuigh a branch from another branch or commit to another commit17:08
*** chris456 <chris456!> has quit IRC17:09
fraySo 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
marler8997what alternative would you suggest?17:10
marler8997it'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 dependencies17:11
frayWhat 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@> has quit IRC17:11
fraynote breaking the repository up == into branches OR separage SCMs.. (I've done both)17:11
marler8997We 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 permissions17:11
fraydepends 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
fraybut if it's simply a permissions management concern, you can do it by branch instead..17:12
marler8997that's going to be alot more work than the problem we have now, we'd be trading one problem for a much bigger problem17:12
*** w00die <w00die!~w00die@> has joined #yocto17:13
fraymodule1/master module2/master module3/master  then have a script that generates these adn keeps them up to date as post-process checkins17:13
smurrayperhaps 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
marler8997smurray, that doesn't solve the problem either because the entire recipe gets rebuilt even when only one project gets modified17:14
frayYou have to remember SCM / branch / commit is ONE project..17:14
smurraymarler8997: such is life, you can't have everything17:14
fraydirectories are not projects, they're part of them..  but it's up to your infrastructure and desired way to work17:14
marler8997that's not really a helpful pience of advice lol17:14
marler8997I ask a question, "how do I do this" and I get an answer "you can't have everything"17:15
marler8997fray so far you haven't given me an alternative that is any better17:15
fraythere 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 log17:15
marler8997you can say that "directories are not projects" but that doesn't mean it's true17:15
marler8997in our case, we have a single repository with multiple small projects inside it17:15
frayWIth the way an SCM (at a high level) is designed, an SCM is a 'project'.. an independent group of things..17:16
frayYes, 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
marler8997ok you've answered my question17:16
fraynothing more that I can suggest other then review it and break it apart..  long term it will be better17:16
marler8997I may add a prepend task to do fetch that allows me to specify a SRC_URL with a repository and a subdirectory17:17
frayYou would be overriding the bitbake download, which means no cached download sources17:17
marler8997I could have each project provide the hash to the subdirectory, then after it's fetched it could verify the hash17:17
frayThis may work internally for you, but won't work in the general case17:17
marler8997yocto's git downloader is horrible anyway17:18
frayA lot of people using YP require downloads to come from a local cache directory.. so by passing that will make it impossible to use17:18
marler8997it downloads the whole repository, then creates a compressed archive from it!17:19
fraywhich part?17:19
frayYou can do shallow clones you knwo17:19
marler8997we build webkit inside yocto, it takes 20 minutes to download, then over 40 minutes to create the compressed archive17:19
frayif you don't want the history for any reason (or a limited amount) just enable shallow cloning17:19
marler8997it's the creating the archive that takes the most time (not the download)17:20
frayAgain, shallow clone vs full clone.. full clone is default17:20
marler8997irrelevant to the archive creation17:20
frayshallow clones are much smaller, as they don't have any hiustory behind them17:20
frayyou can also avoid creating an archive and use the git directly as well17:20
fraythese are simply switches to be flipped17:21
marler8997well I figured it was smart enough not to archive the git history17:21
marler8997are you saying it archives the .git directory as well?17:21
kergothmarler8997: if you don't want the archives for mirror population, disable mirror tarball generation17:21
kergothor switch to shallow tarball usage, as fray said17:21
frayYes, the whole point of the downloads is reproducibility with no network access.. so it ONLY archives teh .git directory17:21
kergothsomewhere in your setup enables BB_GENERATE_MIRROR_TARBALLS. if you don't want it, don't use it17:21
frayturn off git archives, and it won't archive them..17:21
frayturn on shallow cloning and it will only fetch a limited set of commits..17:22
marler8997it only archive the .git directory...what?17:22
marler8997that's definitely not what I remember seeing in the logs and the source17:22
fraycost 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 component17:22
marler8997I saw that it archives the source, then extracts that archive into WORKDIR17:22
frayWhat I am referring to is specific to git repositories..17:22
marler8997yes, I'm only talking about git repositories as well17:23
frayother SCMs may work different17:23
rburtonmarler8997: maybe explain exactly what steps you're talking about17:23
frayya, the system does 'git clone --bare .....' takes the result (and if tarballs are enabled) will then tar up those contents..17:23
marler8997when 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 WORKDIR17:24
marler8997I created a "fastgit.bbclass" that uses a different mechanism and saved the 40 minutes on our webkit build17:24
frayyes, it downloads, via 'git clone --bare <url>' and archives what you did.. you can turn OFF the archive step, that is what we're saying17:24
marler8997sure, but then you said it only archived the .git directory17:25
rburtonwhat else would you want archived?17:25
marler8997everything except the .git directory17:25
fraylook at that17:25
rburtonyou really want to do what fray  and kergoth  have told you repeatedly, and turn off the thing you're upset at17:26
rburtonas it's not on by default17:26
frayIf you are seeing the system archive them, then someone has turned on BB_GENERATE_MIRROR_TARBALLS in yoru build.. set it to 017:26
frayit won't do the archiving step17:26
qschulzmarler8997: haven't read the whople discussion, what about subpath= of the git fetcher?17:27
marler8997subpath is not what we're looking for, it puts the src into a subdir, it doesn't just take a subdir of the SRC17:27
fraymore up to date link:
rburtonthe 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 rebiuilds17:27
qschulzmarler8997: no, read again17:27
marler8997> Places the file (or extracts its contents) into the specified subdirectory of WORKDIR17:28
rburtonthe 20 minute download should be  *once* as presumably you're sharing DL_DIR between builds.  if not, do.17:28
marler8997qschulz, again, not what I was asking about17:28
qschulz"subpath": Limits the checkout to a specific subpath of the tree. By default, the whole tree is checked out.17:28
frayYou were complaing your system was cloning, archiving and then extracting17:28
fraywe're telling you why and how to turn that off17:28
marler8997rburton, yes, all this goes away after the first build17:28
*** bhstalel <bhstalel!c15f633e@> has quit IRC17:29
marler8997fray yes I see that17:29
marler8997thank you for the suggestion there, I will have to try that out17:29
marler8997but I was confused by you saying that it only archived the .git directory17:29
fraythe 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 clone17:30
frayI was making an equivalence17:30
marler8997oh qschulz, subpath!17:30
marler8997I thought it was "subdir"17:30
frayyou won't see a .git directory inside of a bare clone..17:30
marler8997fray, oh I didn't realize it was a bare clone17:30
marler8997so it does a bare clone, archives that17:31
frayand you can speed up the bare clone by using a 'shallow' clone17:31
frayI'm not sure where the docs are for the shallow cloning though..17:31
frayI rarely use it17:31
marler8997so then after it extracts it needs to checkout a specific commit from the bare repository?17:31
rburtonobviously when you clone another repo that's on disk the .git basically just says 'look there'17:32
rburtonso the local clone is super fast17:32
kergothbitbake can't currently directly do a bare clone due to the current fetcher design. recipes may specify an exact revision to check out17:32
kergothand you can't clone a depth from a revision, that's a git limitation17:32
rburtonkergoth: time for fetch317:33
kergothso the only thing we support is creating and using shallow git tarballs17:33
kergothi.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 whatever17:33
frayAhh didn't realize it was no archive _or_ shallow17:33
kergothtechnically shallow clone would work with autorev, i guess, but that'd be it17:33
kergothwe don't know the precise depth from branch HEAD to the commit we want, so we can't specify it with --depth17:33
frayYa, I've only used shallow with autorev before17:33
marler8997when was this subpath option added to the Git fetcher?17:34
*** mckoan is now known as mckoan|away17:34
marler8997actually I'm guessing it won't work either, because it's the SRCREV that's used in the recipe hash I believe17:34
frayadb78a15e (Yu Ke              2011-01-19 00:22:13 +0800 464)         subdir = ud.parm.get("subpath", "")17:34
marler8997There probably isn't a way to specify a subpath hash17:34
fraythat was the _latest_ it could have been added, but I'm pretty sure it was there before17:34
fraynoy uo can not hash the subpath.. the hash is still on the git commit id17:34
smurraymarler8997: 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 uses17:35
marler8997gotcha, so doesn't solve the problem :(17:35
marler8997would probably be a simple feature to add though17:36
frayNo 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 about17:36
*** amitk <amitk!~amit@unaffiliated/amitk> has quit IRC17:36
marler8997when 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 hash17:36
*** pharaon2502 <pharaon2502!> has quit IRC17:36
marler8997fray yes, two different problems17:36
marler8997there are alot of people talking so I'm sorry if it's confusing who I'm responding to and which problem I'm referring to17:37
*** wz <wz!> has quit IRC17:37
*** tlwoerner <tlwoerner!~tlwoerner@unaffiliated/tlwoerner> has quit IRC17:37
*** pharaon2502 <pharaon2502!> has joined #yocto17:37
marler8997I was saying that means subpath doesn't solve the first problem17:37
marler8997it could be used to help solve it though, with the extra functionality I specified above17:38
marler8997SRCREV_SUBPATH = "abcdefg..."17:39
kergothsrcrev 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 former17:41
marler8997you would still need SRCREV17:42
qschulzwell, 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@> has joined #yocto17:42
marler8997qschulz, yes that would also work17:42
marler8997that comes with it's own problem as well though17:43
qschulznothing's free :)17:43
qschulzyou can see that your initial choice of everything in one git is already costing you :)17:43
marler8997it seems to be the cheapest solution so far17:43
marler8997moving to a "one repo per project" would be quite a high cost17: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
marler8997It seems pretty straightforward to me17:44
marler8997the 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
qschulzSRCREV_SUBPATH is irrelevant since you have a recipe per project in your one git repo?17:46
qschulzor maybe I missed something (a lot went on :/)17:47
marler8997the 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_SUBPATH17:47
qschulzI don't get it. You have a git repo with 40 small projects right?17:48
qschulzYou have 40 recipes, one for each project?17:48
qschulzthen one recipe has SRC_URI with subpath, and SRCREV17:48
qschulzthat's it?17:48
frayqschulz sounds like one SCM with a bunch of related, but sepeate projects..  it's not unusual in companies I've worked with..17:49
qschulzand SRCREV is *NOT* in common with all recipes17:49
marler8997we don't use subpath at all right now, but the idea was they could all use subpath17:49
marler8997it IS common to all recipes17:49
marler8997we put the SRCREV in a class17:49
qschulzmarler8997: then don't17:49
marler8997that they all inherit from17:49
marler8997again, having a different SRCREV in every recipe comes with it's own problems17:49
marler8997for example. for projects that depend on each other, they can get out of sync17:49
qschulzthat's maintenance17:50
qschulzbut yeah17:50
qschulzYou'll have to make compromise somewhere17:50
marler8997not really helpful advice though is it?17:50
qschulzbe it that you add support for the SRCREC_SUBPATH you're talking about or not17:50
marler8997what I'm asking for isn't impossible, nor difficult, it just sounds like it hasn't been implemented17:51
kergothIf 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 patch17:51
frayIf you can find native git commands to do it, then it's possible.. otherwise it really is a custom request..17:51
qschulzmarler8997: 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 one17:51
marler8997kergeroth yes I agree17:51
marler8997this is clearly not as common of a use case as one project per repository17:52
kergothbut i doubt anyone else will do it for you, lacking the impetus that's driving you now17:52
marler8997not sure what your point is though17:52
marler8997lol, I never said anyone would17:52
marler8997who are you talking to?17:52
marler8997sounds like you're talking to some weird alternate reality version of me17:53
*** wz <wz!> has joined #yocto17:53
kergothUh, weirdly defensive there. I didn't claim you said someone would, only clarified that if you wanted it done, you'd need to do it17:53
marler8997qshulz, 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 given17:54
marler8997"come on, we gave you multiple ways to do it"17:54
qschulzyou exhausted my patience for today, I'll let you with other people. Good luck17:55
marler8997qschulz, you are the one asking questions, you can stop asking them at any time17:56
*** wz <wz!> has quit IRC17:58
*** dleppich <dleppich!> has quit IRC17:59
*** onkelpit <onkelpit!> has quit IRC18:01
*** RobertBerger <RobertBerger!~rber@> has quit IRC18:09
*** tlwoerner <tlwoerner!~tlwoerner@unaffiliated/tlwoerner> has joined #yocto18:09
*** onkelpit <onkelpit!> has joined #yocto18:10
*** learning <learning!bb14930d@> has joined #yocto18:11
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC18:11
*** kaspter <kaspter!~Instantbi@> has quit IRC18:17
*** kaspter <kaspter!~Instantbi@2409:8a1e:911b:1000:d165:4a24:ce2b:3f45> has joined #yocto18:18
*** Kyubi <Kyubi!~Kyubi@> has quit IRC18:21
codypsHi 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
codypsAny 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
codypsI'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@> has joined #yocto18:30
*** dev1990 <dev1990!> has quit IRC18:30
fraytarget 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 it18:31
fray(check etc/passwd and etc/group inside of the target roofs)18:32
stacktrustDoes the Yocto autobuilder share a public sstate cache for dunfell and qemuarm64 machine?18:36
*** RobertBerger <RobertBerger!~rber@> has joined #yocto18:42
rburtonits mentioned in the sample local.conf iirc18:42
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC18:45
codypsfray: 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 thanks18:49
*** learning <learning!bb14930d@> has quit IRC18:49
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto18:49
codypsah, 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
codypsthat `etc/group` also has a man group.18:50
codypsIs there something in the log.do_populate_sdk which would indicate which sysroot exactly pseudo is using here?18:56
*** kiwi_29 <kiwi_29!> has joined #yocto19:05
*** wz <wz!> has joined #yocto19:07
*** kpo_ <kpo_!> has quit IRC19:13
*** kpo_ <kpo_!> has joined #yocto19:14
*** leon-anavi <leon-anavi!~Leon@> has quit IRC19:14
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto19:14
*** kaspter <kaspter!~Instantbi@2409:8a1e:911b:1000:d165:4a24:ce2b:3f45> has quit IRC19:19
*** sakoman <sakoman!> has quit IRC19:20
moto-timostacktrust: but you need to change the version to point to it... I think it still says 2.5 in the local.conf.sample19:27
*** yann <yann!~yann@> has quit IRC19:28
*** xtopher <xtopher!~xtopher@2600:380:445e:2f5b:a192:9459:4a40:ed16> has joined #yocto19:34
xtopheram 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:;downloadfilename=PATH but don't seem to be seeing a lot of cache hits / acceleration19:37
xtopherwould switching from rpm to ipk be expected to change the hit rate a lot?19:37
xtophermaybe the version should be 3.1.4 in the url?19:39
*** alessioigor <alessioigor!> has joined #yocto19:40
*** gonkulator <gonkulator!~brandon@> has quit IRC19:42
*** wz <wz!> has quit IRC19:47
*** gonkulator <gonkulator!~brandon@> has joined #yocto19:50
*** kiwi_29 <kiwi_29!> has quit IRC19:51
*** kiwi_29 <kiwi_29!> has joined #yocto19:53
*** paulg <paulg!> has quit IRC19:53
*** paulg <paulg!> has joined #yocto19:54
*** kiwi_29 <kiwi_29!> has quit IRC19:54
*** kiwi_29 <kiwi_29!> has joined #yocto19:54
xtopherIt 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 #yocto19:56
*** dagmcr <dagmcr!sid323878@gateway/web/> has quit IRC20:03
*** awafaa <awafaa!sid716@gateway/web/> has quit IRC20:03
*** rsalveti <rsalveti!uid117878@gateway/web/> has quit IRC20:03
*** rsalveti <rsalveti!uid117878@gateway/web/> has joined #yocto20:04
*** dagmcr <dagmcr!sid323878@gateway/web/> has joined #yocto20:04
*** awafaa <awafaa!sid716@gateway/web/> has joined #yocto20:04
codypsWelp, 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
codypsI 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!> has quit IRC20:12
*** alessioigor <alessioigor!> has quit IRC20:20
*** Kyubi <Kyubi!~Kyubi@> has quit IRC20:21
zeddiiRP: 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@> has joined #yocto20:25
*** bluelightning_ is now known as bluelightning20:36
smurrayzeddii: heh, 5.10.1? ;)20:37
zeddiias of 10 minutes ago, its still rebuilding20:38
zeddiibut if greg busted us in .1, that's a shin-kicking20:38
zeddiia .1 half an hour after the release is a brown paper bag fix20:39
paulbarkerI saw that before20:41
paulbarkerbtrfs raid6 mounting issue I believe20:42
smurrayyeah, definitely a brown paper bag bug20:42
paulbarkerTBH anyone using btrfs raid5/6 is a daredevil anyway20:42
zeddiitruth! which is why I'd never, ever see that issue.20:43
*** stzsch <stzsch!~stzsch@> has joined #yocto20:46
*** onkelpit <onkelpit!> has quit IRC20:47
*** bobo <bobo!> has joined #yocto20:50
*** gonkulator <gonkulator!~brandon@> has joined #yocto20:50
*** habing <habing!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has joined #yocto20:50
*** xtopher <xtopher!~xtopher@2600:380:445e:2f5b:a192:9459:4a40:ed16> has quit IRC20:57
*** wz <wz!> has joined #yocto21:11
*** habing <habing!~habing@2a02:8388:6c0:1200:269c:52c3:be0c:e984> has quit IRC21:22
*** kiwi_29 <kiwi_29!> has quit IRC21:37
RPzeddii: it was really the previous release which was why it worked so smoothly but they're fixing in .1? :)21:40
RPzeddii: seriously, that sounds good to be able to look at other things for a change21:40
*** Shikadi` <Shikadi`!> has joined #yocto21:46
*** xtopher <xtopher!~xtopher@2600:380:445e:2f5b:a192:9459:4a40:ed16> has joined #yocto21:49
*** Konsgnx1 <Konsgnx1!> has joined #yocto21:50
*** Konsgn <Konsgn!~Konsgnx3@unafiliated/joyseph> has quit IRC21: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 driver21:50
*** vineela <vineela!~vtummala@> has quit IRC21:51
xtopher5.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-6421:52
*** vineela <vineela!vtummala@nat/intel/x-chwcxnjhaskclxaf> has joined #yocto22:00
*** paulg <paulg!> has quit IRC22:01
*** paulg <paulg!> has joined #yocto22:01
*** grumble <grumble!~Thunderbi@freenode/staff/grumble> has quit IRC22:03
*** xtopher <xtopher!~xtopher@2600:380:445e:2f5b:a192:9459:4a40:ed16> has quit IRC22:04
*** grumble <grumble!~Thunderbi@freenode/staff/grumble> has joined #yocto22:12
*** Kyubi <Kyubi!~Kyubi@> has quit IRC22:21
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto22:34
*** lexano <lexano!> has quit IRC22:41
*** lexano <lexano!> has joined #yocto22:43
*** kiwi_29 <kiwi_29!> has joined #yocto22:52
mischieflets say i have N machines. should they be in N different layers or one layer? why?22:57
*** paulg <paulg!> has quit IRC23:12
*** leon-anavi <leon-anavi!~Leon@> has quit IRC23:14
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto23:14
*** wz <wz!> has quit IRC23:15
*** kiwi_29 <kiwi_29!> has quit IRC23:18
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC23:19
*** paulg <paulg!> has joined #yocto23:25
*** goliath <goliath!> has quit IRC23:25
*** kiwi_29 <kiwi_29!> has joined #yocto23:29
*** wz <wz!> has joined #yocto23:34
*** kiwi_29 <kiwi_29!> has quit IRC23:34
*** leon-anavi <leon-anavi!~Leon@> has quit IRC23:35
*** agust <agust!> has quit IRC23:37
*** kpo_ <kpo_!> has quit IRC23:37
*** kpo_ <kpo_!> has joined #yocto23:38
*** radsquirrel <radsquirrel!~radsquirr@> has quit IRC23:40
*** radsquirrel <radsquirrel!~radsquirr@2603:3015:e15:5bf2:d0b3:d9ff:fede:b022> has joined #yocto23:40
codypshmmm... 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 this23:41
*** gendevbot_ <gendevbot_!~devbot@> has quit IRC23:44
*** gendevbot <gendevbot!~devbot@> has joined #yocto23:45
*** kiwi_29 <kiwi_29!> has joined #yocto23:53
*** kiwi_29 <kiwi_29!> has quit IRC23:58

Generated by 2.17.2 by Marius Gedminas - find it at!