**** BEGIN LOGGING AT Mon Dec 14 03:00:00 2020 Dec 14 03:14:43 hah. sounds painful. Dec 14 03:15:03 I'm spelunking in the k3s build scripts to see if the recipe is missing something .. nothing obvious so far. Dec 14 04:21:11 zeddii: trust me, I stared at it for a while and found nothing Dec 14 04:21:44 I'm trying to find exactly how the reference one is built. ours is simply garbage. Dec 14 04:21:56 drop in the k3s binary, everything else the same. magic. Dec 14 04:22:15 I'm building the exact same git hash, so it has to be something else in the cross build breaking it, or a config. Dec 14 04:22:46 I know. I fuckng hate that voodooo bullshit Dec 14 04:22:49 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. Dec 14 04:23:12 I loathe the way go builds Dec 14 04:23:14 #2020 #dumpsterfire Dec 14 04:23:24 go can just go Dec 14 04:23:52 like why does k0s build gloriously the first time and then BITCH the xecond time? Dec 14 04:23:58 f' you Dec 14 04:24:02 yup. 11pm on a sunday, I'm moving off to call it a day. will work on this during the day tomorrow. Dec 14 04:24:26 I successfully built kicad nightly on a raspberrypi400 Dec 14 04:24:34 I have spoken Dec 14 04:24:38 :D Dec 14 04:24:59 I thought it was Monday Dec 14 04:25:01 FUck me Dec 14 04:25:12 hahah. blame your sabattical! Dec 14 04:25:24 * moto-timo has lost his filter... forgive me it is sabbatical and #2020 Dec 14 04:25:33 lol Dec 14 04:25:40 I'm going to drool over some netflix and maybe get inspired to try another tactic tomorrow! Dec 14 04:25:42 catch you later! Dec 14 04:25:53 g'night zeddii Dec 14 04:25:58 may the force be with you Dec 14 04:26:29 as always, ping me with random crap Dec 14 07:00:22 hello :) Dec 14 07:32:53 morning Dec 14 07:38:21 morning! Dec 14 07:48:42 yo dudX Dec 14 08:03:35 morning Dec 14 08:23:56 good morning Dec 14 09:11:26 hello there Dec 14 09:19:07 yo qschulz Dec 14 09:54:09 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 Dec 14 09:54:57 some trys fail as the toolchain then misses paths , some fail because my lack of autotool knowledge Dec 14 09:59:58 rob_w: any particular requirement nailing you down on autotools then, if you're already having problems with it? Dec 14 10:01:02 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 Dec 14 10:01:27 but i want that 1.c 2.c 3.c etc are compile via make -j X .. in parallel so to speak Dec 14 10:01:42 but it compiles one after the other Dec 14 10:02:24 so i understand that i would need to specify the 1.o 2.o 3.o as seperate targets ? Dec 14 10:04:17 my knowledge there is pretty limited too, but i dont think that this is the case. Dec 14 10:21:34 Hi, I don't want to interrupt an active conversation but I have an urgent question: Dec 14 10:21:46 I have an LCD display Dec 14 10:22:07 Where to put the video parameter ? in uboot devicetree bootargs ? Dec 14 10:22:21 Or somewhere in the kernel ? Dec 14 10:23:07 The LCD interface in MIPI DSI Dec 14 10:25:44 video parameters? Dec 14 10:28:37 bhstalel: machine name ? Dec 14 10:29:45 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 Dec 14 10:33:03 bhstalel: in u-boot, it is the kernel command line Dec 14 10:33:59 put it into the bootargs u-boot env variable Dec 14 10:35:27 Okay , I'll look into it, thanks all :)))) Dec 14 10:40:52 well my problem just resolved .. i realized my code would not gain compile speed even with parallel make -j .. thx anyway Dec 14 10:41:31 90% of my time is coming from one particular .c file .. so until i split this up it is what it is Dec 14 11:31:44 i want to compile a go program and i got an erro: https://codeshare.io/GkV64x Dec 14 11:32:10 do i have to add a specific "go"-layer or should it work out of the box? Dec 14 11:32:42 RP: can you take a look at "Strange segfault on native Go binaries" on ml? Dec 14 11:33:18 chris456: on recent Yocto Project releases, we have Go support on OE-Core Dec 14 11:33:52 otavio: I had seen it. Are you using sstate generated by the nixos system on the ubuntu one? Dec 14 11:34:46 otavio: I'd suspect some kind of patchelf problem, particularly as nixos uses patchelf extensively itself Dec 14 11:36:17 octavio: https://layers.openembedded.org/layerindex/recipe/60594/ <- this one? Dec 14 11:36:32 RP: no, I did it all inside the docker Dec 14 11:37:27 RP: I did not run it inside the nixos. As I mentioned to khem I am using a Docker container with Ubuntu 20.04 Dec 14 11:48:58 RP: I believe it is reproducible there. Dec 14 11:56:51 otavio: at that point you probably have to try and see if patchelf is breaking the binary... Dec 14 11:59:03 RP: can you tell me where to look? Dec 14 11:59:14 I can check, for sure Dec 14 12:03:47 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 Dec 14 12:04:11 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? Dec 14 12:05:02 otavio: there are also chrpath calls from chrpath.bbclass which may edit the binary so those could also be a potential cause Dec 14 13:33:20 rburton: I think the syslinux changes aren't happy: https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/1654/steps/14/logs/stdio Dec 14 13:37:44 I'll reply on list so aesh can see it Dec 14 13:46:41 bah Dec 14 13:47:23 isohybrid: not found Dec 14 13:47:33 well at least it wasn't something i did to syslinux directly Dec 14 13:54:03 rburton: doesn't look too serious to fix Dec 14 13:54:27 you say that Dec 14 13:54:29 this is syslinux Dec 14 13:55:45 rburton: I'm trying to be positive ;-) Dec 14 13:55:58 rburton: I can tell you you're doomed if you like ;-) Dec 14 14:03:35 kicking a selftest run to verify the patches before submitting Dec 14 14:45:39 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? Dec 14 14:46:40 each bbappend would add the proper extended attribute to the installed files Dec 14 14:50:25 don't know about smack but that sounds like a good use for something handled on the distro level? Dec 14 14:51:33 tardyp: there's a worked example of using smack in tizen/iot-dev-kit if you dig out the old repos Dec 14 14:51:41 not sure of anyone using it since then though Dec 14 14:52:14 tardyp: are the bbappend files similar and boilerplate? If so there are other ways you could inject into all recipes Dec 14 14:52:29 if they're custom to each recipe that gets harder Dec 14 14:53:31 we need to split our fs into a dozen domain, and then inject the right xattr to each file according to their domain Dec 14 14:54:24 are there any package managers that successfully package up extended attributes? Dec 14 14:54:52 I saw an old email saying it wasn't obvious Dec 14 14:56:09 tardyp: there are hooks during packaging for example where you could hook in such a generic processing function Dec 14 14:57:14 AGL uses postinst to do the labeling on first boot Dec 14 14:59:21 https://www.irccloud.com/pastebin/cbCrbAJm/ Dec 14 15:00:16 I saw something like this indeed. not sure if this is really scalable Dec 14 15:00:40 not sure how AGL does it, but a class you can globally inherit to write a postinst would be fairly simple to write Dec 14 15:01:52 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. Dec 14 15:01:54 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 ;) ) Dec 14 15:02:12 smurray: i've done incredibly well by not asking anything about AGL so far ;) Dec 14 15:02:37 rburton: heh Dec 14 15:04:12 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 Dec 14 15:05:23 mkfs.ext4 is not capable of creating xattr at the beginning, right? Dec 14 15:06:14 I mean at the image creation time Dec 14 15:25:40 tardyp: not that I'm aware of Dec 14 15:31:37 hmm ... mkfs.ext4 -O flag ? maybe ? Dec 14 15:46:09 dl9pf: that's for filesystem features AFAIK? Dec 14 15:48:37 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... Dec 14 15:52:18 and the easiest thing that comes to mind is loopback mounting, which seems potentially problematic wrt doing it as non-root Dec 14 16:01:12 right, right. Dec 14 16:04:11 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 Dec 14 16:04:40 both options looks quite complicated for the usecase :-/ Dec 14 16:13:57 tardyp: right, there's a reason why most distros end up doing it at boot Dec 14 16:15:47 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 Dec 14 16:54:31 zeddii, really Dec 14 16:56:26 really! Dec 14 16:56:29 :D Dec 14 17:02:59 Is there a way to specify a sub directory in a SRC_URI resource such that yocto only hashes what is inside the subdirectory? Dec 14 17:05:38 marler8997: you can give a directory to SRC_URI yes Dec 14 17:05:47 file://dir or file://dir/ will work Dec 14 17:05:58 everything in it will be taken Dec 14 17:06:05 DO NOT USE PATTERNS Dec 14 17:06:20 I repeat, DO NOT USE PATTERNS (globs, regexp, whatever) it does NOT work Dec 14 17:06:32 we have a repository where we keep around 40 small projects Dec 14 17:06:54 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 Dec 14 17:07:09 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) Dec 14 17:07:13 but that means when any one project changes, the hash changes for all the projects Dec 14 17:07:34 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' Dec 14 17:07:45 I don't think *yocto doesn't support this use case* means *this is a bad use case* Dec 14 17:07:58 first, I haven't established yet whether yocto support this or not Dec 14 17:08:18 Yocto Project CAN share a single SCM across recipes.. easily.. we do it all the time Dec 14 17:08:30 yes I know, that's what we're doing Dec 14 17:08:45 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 Dec 14 17:09:52 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) Dec 14 17:10:07 what alternative would you suggest? Dec 14 17:11:01 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 Dec 14 17:11:09 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.. Dec 14 17:11:49 note breaking the repository up == into branches OR separage SCMs.. (I've done both) Dec 14 17:11:50 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 Dec 14 17:12:31 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.. Dec 14 17:12:43 but if it's simply a permissions management concern, you can do it by branch instead.. Dec 14 17:12:57 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 Dec 14 17:13:19 module1/master module2/master module3/master then have a script that generates these adn keeps them up to date as post-process checkins Dec 14 17:13:28 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... Dec 14 17:14:06 smurray, that doesn't solve the problem either because the entire recipe gets rebuilt even when only one project gets modified Dec 14 17:14:27 You have to remember SCM / branch / commit is ONE project.. Dec 14 17:14:30 marler8997: such is life, you can't have everything Dec 14 17:14:44 directories are not projects, they're part of them.. but it's up to your infrastructure and desired way to work Dec 14 17:14:50 that's not really a helpful pience of advice lol Dec 14 17:15:09 I ask a question, "how do I do this" and I get an answer "you can't have everything" Dec 14 17:15:31 fray so far you haven't given me an alternative that is any better Dec 14 17:15:39 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 Dec 14 17:15:44 you can say that "directories are not projects" but that doesn't mean it's true Dec 14 17:15:55 in our case, we have a single repository with multiple small projects inside it Dec 14 17:16:10 WIth the way an SCM (at a high level) is designed, an SCM is a 'project'.. an independent group of things.. Dec 14 17:16:37 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. Dec 14 17:16:44 ok you've answered my question Dec 14 17:16:52 nothing more that I can suggest other then review it and break it apart.. long term it will be better Dec 14 17:17:03 I may add a prepend task to do fetch that allows me to specify a SRC_URL with a repository and a subdirectory Dec 14 17:17:31 You would be overriding the bitbake download, which means no cached download sources Dec 14 17:17:34 I could have each project provide the hash to the subdirectory, then after it's fetched it could verify the hash Dec 14 17:17:41 This may work internally for you, but won't work in the general case Dec 14 17:18:50 yocto's git downloader is horrible anyway Dec 14 17:18:57 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 Dec 14 17:19:06 it downloads the whole repository, then creates a compressed archive from it! Dec 14 17:19:07 which part? Dec 14 17:19:13 lol Dec 14 17:19:26 You can do shallow clones you knwo Dec 14 17:19:39 we build webkit inside yocto, it takes 20 minutes to download, then over 40 minutes to create the compressed archive Dec 14 17:19:39 if you don't want the history for any reason (or a limited amount) just enable shallow cloning Dec 14 17:20:00 it's the creating the archive that takes the most time (not the download) Dec 14 17:20:16 Again, shallow clone vs full clone.. full clone is default Dec 14 17:20:27 irrelevant to the archive creation Dec 14 17:20:36 No.. Dec 14 17:20:47 shallow clones are much smaller, as they don't have any hiustory behind them Dec 14 17:20:56 you can also avoid creating an archive and use the git directly as well Dec 14 17:21:01 these are simply switches to be flipped Dec 14 17:21:02 well I figured it was smart enough not to archive the git history Dec 14 17:21:10 are you saying it archives the .git directory as well? Dec 14 17:21:20 marler8997: if you don't want the archives for mirror population, disable mirror tarball generation Dec 14 17:21:29 or switch to shallow tarball usage, as fray said Dec 14 17:21:35 Yes, the whole point of the downloads is reproducibility with no network access.. so it ONLY archives teh .git directory Dec 14 17:21:45 somewhere in your setup enables BB_GENERATE_MIRROR_TARBALLS. if you don't want it, don't use it Dec 14 17:21:48 turn off git archives, and it won't archive them.. Dec 14 17:22:01 turn on shallow cloning and it will only fetch a limited set of commits.. Dec 14 17:22:14 it only archive the .git directory...what? Dec 14 17:22:37 that's definitely not what I remember seeing in the logs and the source Dec 14 17:22:38 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 Dec 14 17:22:50 I saw that it archives the source, then extracts that archive into WORKDIR Dec 14 17:22:51 What I am referring to is specific to git repositories.. Dec 14 17:23:01 yes, I'm only talking about git repositories as well Dec 14 17:23:05 other SCMs may work different Dec 14 17:23:24 marler8997: maybe explain exactly what steps you're talking about Dec 14 17:23:25 ya, the system does 'git clone --bare .....' takes the result (and if tarballs are enabled) will then tar up those contents.. Dec 14 17:24:12 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 Dec 14 17:24:48 I created a "fastgit.bbclass" that uses a different mechanism and saved the 40 minutes on our webkit build Dec 14 17:24:50 yes, it downloads, via 'git clone --bare ' and archives what you did.. you can turn OFF the archive step, that is what we're saying Dec 14 17:25:11 sure, but then you said it only archived the .git directory Dec 14 17:25:21 what else would you want archived? Dec 14 17:25:37 everything except the .git directory Dec 14 17:25:51 https://www.yoctoproject.org/docs/1.7/ref-manual/ref-manual.html#var-BB_GENERATE_MIRROR_TARBALLS Dec 14 17:25:55 look at that Dec 14 17:26:12 you really want to do what fray and kergoth have told you repeatedly, and turn off the thing you're upset at Dec 14 17:26:19 as it's not on by default Dec 14 17:26:27 If you are seeing the system archive them, then someone has turned on BB_GENERATE_MIRROR_TARBALLS in yoru build.. set it to 0 Dec 14 17:26:33 it won't do the archiving step Dec 14 17:27:02 marler8997: haven't read the whople discussion, what about subpath= of the git fetcher? Dec 14 17:27:32 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 Dec 14 17:27:34 more up to date link: https://docs.yoctoproject.org/ref-manual/ref-variables.html?highlight=bb_generate_mirror_tarballs#term-BB_GENERATE_MIRROR_TARBALLS Dec 14 17:27:44 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 Dec 14 17:27:53 marler8997: no, read again Dec 14 17:28:27 > Places the file (or extracts its contents) into the specified subdirectory of WORKDIR Dec 14 17:28:29 the 20 minute download should be *once* as presumably you're sharing DL_DIR between builds. if not, do. Dec 14 17:28:37 qschulz, again, not what I was asking about Dec 14 17:28:51 "subpath": Limits the checkout to a specific subpath of the tree. By default, the whole tree is checked out. Dec 14 17:28:51 You were complaing your system was cloning, archiving and then extracting Dec 14 17:28:58 we're telling you why and how to turn that off Dec 14 17:28:59 rburton, yes, all this goes away after the first build Dec 14 17:29:24 fray yes I see that Dec 14 17:29:34 thank you for the suggestion there, I will have to try that out Dec 14 17:29:36 https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-fetching.html#git-fetcher-git Dec 14 17:29:47 but I was confused by you saying that it only archived the .git directory Dec 14 17:30:14 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 Dec 14 17:30:19 I was making an equivalence Dec 14 17:30:25 oh qschulz, subpath! Dec 14 17:30:32 I thought it was "subdir" Dec 14 17:30:33 you won't see a .git directory inside of a bare clone.. Dec 14 17:30:54 fray, oh I didn't realize it was a bare clone Dec 14 17:31:04 so it does a bare clone, archives that Dec 14 17:31:13 and you can speed up the bare clone by using a 'shallow' clone Dec 14 17:31:31 I'm not sure where the docs are for the shallow cloning though.. Dec 14 17:31:36 I rarely use it Dec 14 17:31:45 so then after it extracts it needs to checkout a specific commit from the bare repository? Dec 14 17:31:50 yes Dec 14 17:31:54 gotcha Dec 14 17:32:18 obviously when you clone another repo that's on disk the .git basically just says 'look there' Dec 14 17:32:25 so the local clone is super fast Dec 14 17:32:36 bitbake can't currently directly do a bare clone due to the current fetcher design. recipes may specify an exact revision to check out Dec 14 17:32:43 and you can't clone a depth from a revision, that's a git limitation Dec 14 17:32:59 kergoth: time for fetch3 Dec 14 17:33:02 so the only thing we support is creating and using shallow git tarballs Dec 14 17:33:21 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 Dec 14 17:33:23 Ahh didn't realize it was no archive _or_ shallow Dec 14 17:33:38 technically shallow clone would work with autorev, i guess, but that'd be it Dec 14 17:33:54 we don't know the precise depth from branch HEAD to the commit we want, so we can't specify it with --depth Dec 14 17:33:58 Ya, I've only used shallow with autorev before Dec 14 17:34:05 when was this subpath option added to the Git fetcher? Dec 14 17:34:34 actually I'm guessing it won't work either, because it's the SRCREV that's used in the recipe hash I believe Dec 14 17:34:39 adb78a15e (Yu Ke 2011-01-19 00:22:13 +0800 464) subdir = ud.parm.get("subpath", "") Dec 14 17:34:45 There probably isn't a way to specify a subpath hash Dec 14 17:34:49 that was the _latest_ it could have been added, but I'm pretty sure it was there before Dec 14 17:34:58 noy uo can not hash the subpath.. the hash is still on the git commit id Dec 14 17:35:14 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 Dec 14 17:35:31 gotcha, so doesn't solve the problem :( Dec 14 17:36:02 would probably be a simple feature to add though Dec 14 17:36:10 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 Dec 14 17:36:26 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 Dec 14 17:36:46 fray yes, two different problems Dec 14 17:37:05 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 Dec 14 17:37:44 I was saying that means subpath doesn't solve the first problem Dec 14 17:38:22 it could be used to help solve it though, with the extra functionality I specified above Dec 14 17:39:07 SRCREV_SUBPATH = "abcdefg..." Dec 14 17:41:11 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 Dec 14 17:42:06 correct Dec 14 17:42:14 you would still need SRCREV Dec 14 17:42:17 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. Dec 14 17:42:49 qschulz, yes that would also work Dec 14 17:43:09 that comes with it's own problem as well though Dec 14 17:43:17 nothing's free :) Dec 14 17:43:30 you can see that your initial choice of everything in one git is already costing you :) Dec 14 17:43:47 it seems to be the cheapest solution so far Dec 14 17:44:03 moving to a "one repo per project" would be quite a high cost Dec 14 17:44:04 (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 :) ) Dec 14 17:44:52 It seems pretty straightforward to me Dec 14 17:45:51 the relevant discussion: can you base recipe hash on git subdirectory? No but subpath can limit the file? we could add a SRCREV_SUBPATH... Dec 14 17:46:49 SRCREV_SUBPATH is irrelevant since you have a recipe per project in your one git repo? Dec 14 17:47:09 or maybe I missed something (a lot went on :/) Dec 14 17:47:09 huh? Dec 14 17:47:36 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 Dec 14 17:48:13 I don't get it. You have a git repo with 40 small projects right? Dec 14 17:48:17 yes Dec 14 17:48:29 You have 40 recipes, one for each project? Dec 14 17:48:32 yes Dec 14 17:48:47 then one recipe has SRC_URI with subpath, and SRCREV Dec 14 17:48:55 that's it? Dec 14 17:49:08 qschulz sounds like one SCM with a bunch of related, but sepeate projects.. it's not unusual in companies I've worked with.. Dec 14 17:49:10 and SRCREV is *NOT* in common with all recipes Dec 14 17:49:11 we don't use subpath at all right now, but the idea was they could all use subpath Dec 14 17:49:25 it IS common to all recipes Dec 14 17:49:29 we put the SRCREV in a class Dec 14 17:49:33 marler8997: then don't Dec 14 17:49:34 that they all inherit from Dec 14 17:49:48 again, having a different SRCREV in every recipe comes with it's own problems Dec 14 17:49:58 for example. for projects that depend on each other, they can get out of sync Dec 14 17:50:11 that's maintenance Dec 14 17:50:15 but yeah Dec 14 17:50:28 You'll have to make compromise somewhere Dec 14 17:50:40 not really helpful advice though is it? Dec 14 17:50:42 be it that you add support for the SRCREC_SUBPATH you're talking about or not Dec 14 17:51:15 what I'm asking for isn't impossible, nor difficult, it just sounds like it hasn't been implemented Dec 14 17:51:45 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 Dec 14 17:51:46 If you can find native git commands to do it, then it's possible.. otherwise it really is a custom request.. Dec 14 17:51:54 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 Dec 14 17:51:58 kergeroth yes I agree Dec 14 17:52:14 this is clearly not as common of a use case as one project per repository Dec 14 17:52:17 but i doubt anyone else will do it for you, lacking the impetus that's driving you now Dec 14 17:52:22 not sure what your point is though Dec 14 17:52:31 lol, I never said anyone would Dec 14 17:52:36 who are you talking to? Dec 14 17:53:05 sounds like you're talking to some weird alternate reality version of me Dec 14 17:53:27 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 Dec 14 17:54:13 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 Dec 14 17:54:20 "come on, we gave you multiple ways to do it" Dec 14 17:55:38 you exhausted my patience for today, I'll let you with other people. Good luck Dec 14 17:56:31 qschulz, you are the one asking questions, you can stop asking them at any time Dec 14 18:25:16 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). Dec 14 18:25:55 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. Dec 14 18:27:45 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. Dec 14 18:28:50 (well, not actually nativesdk packages. `util-linux-doc` is a target package) Dec 14 18:31:16 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 Dec 14 18:32:31 (check etc/passwd and etc/group inside of the target roofs) Dec 14 18:36:50 Does the Yocto autobuilder share a public sstate cache for dunfell and qemuarm64 machine? Dec 14 18:42:01 yes Dec 14 18:42:31 its mentioned in the sample local.conf iirc Dec 14 18:46:40 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`). Dec 14 18:49:00 @rburton thanks Dec 14 18:49:36 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. Dec 14 18:50:42 that `etc/group` also has a man group. Dec 14 18:56:51 Is there something in the log.do_populate_sdk which would indicate which sysroot exactly pseudo is using here? Dec 14 19:27:20 stacktrust: but you need to change the version to point to it... I think it still says 2.5 in the local.conf.sample Dec 14 19:37:21 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 Dec 14 19:37:37 would switching from rpm to ipk be expected to change the hit rate a lot? Dec 14 19:39:00 maybe the version should be 3.1.4 in the url? Dec 14 19:54:52 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. Dec 14 20:05:43 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: Dec 14 20:05:43 https://gist.github.com/4a13dd5729786eb2b7479c13ba1b4216 Dec 14 20:09:24 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). Dec 14 20:24:46 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. Dec 14 20:37:48 zeddii: heh, 5.10.1? ;) Dec 14 20:38:15 yup Dec 14 20:38:29 as of 10 minutes ago, its still rebuilding Dec 14 20:38:41 but if greg busted us in .1, that's a shin-kicking Dec 14 20:39:02 a .1 half an hour after the release is a brown paper bag fix Dec 14 20:41:10 I saw that before Dec 14 20:41:41 zeddii: https://twitter.com/kernellogger/status/1338379381392216065 Dec 14 20:42:00 btrfs raid6 mounting issue I believe Dec 14 20:42:13 ahah Dec 14 20:42:51 yeah, definitely a brown paper bag bug Dec 14 20:42:58 TBH anyone using btrfs raid5/6 is a daredevil anyway Dec 14 20:43:15 truth! which is why I'd never, ever see that issue. Dec 14 21:40:10 zeddii: it was really the previous release which was why it worked so smoothly but they're fixing in .1? :) Dec 14 21:40:26 zeddii: seriously, that sounds good to be able to look at other things for a change Dec 14 21:45:46 +1 Dec 14 21:50:56 @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 Dec 14 21:52:18 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 Dec 14 22:57:06 lets say i have N machines. should they be in N different layers or one layer? why? Dec 14 23:41:51 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 Dec 14 23:41:52 correctly. **** ENDING LOGGING AT Tue Dec 15 02:59:57 2020