**** BEGIN LOGGING AT Wed Feb 24 03:02:58 2021 Feb 24 03:10:22 vdl: i understand. it just sounded like you were saying you didn't need any bootloader for the x86. you do, just not one you compile within the bsp (as you stated). Feb 24 03:10:40 irc is not always the best way to communicate... :) Feb 24 03:10:56 vdl et al.: thank you for the information Feb 24 03:20:18 pardon me if i've asked this recently, and this is not necessarily a yocto question, but which component of a linux build provides the cross toolchain? Feb 24 03:21:47 more specifically, as i understand it, the binutils has to be ported to the processor architecture for which the build is constructed. how is this provided? Feb 24 04:08:25 yates: cross toolchain consists of several components but you need a cross-gcc and cross-binutils at the least to bootstrap Feb 24 04:09:02 you will see binutils-cross and gcc-cross recipes in metadata those will be of interest Feb 24 04:10:24 but since bootstrapping cross toolchains is a bit of voodoo there are some intermediate steps to achieve a fully functional cross toolchain, if you want to learn more look at gcc/ binutils/ linux-libc-headers/ glibc related recipes Feb 24 08:02:16 good morning Feb 24 08:02:44 yo mckoan and rest of dudX Feb 24 08:04:32 :-D Feb 24 09:21:39 mornin' Feb 24 09:54:13 hi Feb 24 09:54:13 i want to add mkisofs with image how i can add this into image ? Feb 24 10:05:51 pankaj34756: IIUC, it's [part of cdrtools, but we only have a native recipe available Feb 24 10:05:56 c.f. https://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb?h=master Feb 24 10:06:06 so you probably need to create one yourself Feb 24 10:06:20 don't know if cross-compilation is supported, but you'll discover by yourself :) Feb 24 10:06:50 qschulz ok..thanks Feb 24 11:26:29 RP: diffoscope is *so slow*. I had to diff two 1gb trees and after six hours I gave up Feb 24 11:26:57 rburton: with master? its hanging for me atm Feb 24 11:27:07 oh, outside of OE Feb 24 11:27:15 I was able to reproduce the hangs quite quickly by adding https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20210224-vy8equte/packages/reproducibleA/tmp/deploy/rpm/noarch/cantarell-fonts-0.301-r0.noarch.rpm to meta/lib/oeqa/selftest/cases/diffoscope/A and it's counterpart to B, then oe-selftest -r reproducible.DiffoscopeTests.test_diffoscope Feb 24 11:27:21 rburton: you need moar power Feb 24 11:27:36 LetoThe2nd: its not multithreaded so adding more power doesn't really help Feb 24 11:27:43 rburton: did you see that arm worker build hang? I had to stop it to unblock all the jobs :/ Feb 24 11:28:00 LetoThe2nd: there must be some bad algorithms as these two 1gb trees were identical apart from ~10 files Feb 24 11:28:15 rburton: more is always more: https://youtu.be/QHZ48AE3TOI Feb 24 11:28:31 rburton: I ended up separating the packages I wanted to diff and running it in parallel Feb 24 11:28:53 RP: the doomed worker or the other worker? Feb 24 11:29:46 rburton: other one Feb 24 11:30:26 rburton: jon delegated to you last night Feb 24 11:32:15 thanks jonmason! Feb 24 11:32:46 we need to get the AB an Altra so the arm builders stop hitting all the timeouts due to being slow Feb 24 11:33:01 rburton: that would be nice Feb 24 11:33:25 rburton: were you using html output or not? That is what seems to hang diffoscope Feb 24 11:33:33 Ah, really Feb 24 11:33:34 Yes, I was Feb 24 11:33:45 rburton: which version out of interest? Feb 24 11:33:53 Some O(N^N) stupidity in the html output? Feb 24 11:33:58 erm, latest a few weeks ago Feb 24 11:34:59 so that hanging job actually finished all the bitbake work Feb 24 11:35:50 but bitbake didn't actually quit Feb 24 11:38:55 rburton: how did you determine that? Feb 24 11:39:11 NOTE: recipe core-image-sato-1.0-r0: task do_testsdkext: Succeeded Feb 24 11:39:11 Bitbake still alive (5000s) Feb 24 11:40:09 hm hang on no Feb 24 11:42:21 rburton: NOTE: recipe core-image-minimal-1.0-r0: task do_testsdkext: Started never finishes Feb 24 11:42:27 right Feb 24 11:42:41 rburton: stop blaming poor bitbake Feb 24 11:42:50 still blaming bitbake :) Feb 24 11:43:32 bit annoying that the logs are just merged Feb 24 11:43:43 when do we get per-task logs in the buildbot Feb 24 11:49:14 rburton: when you implement it. I was happy just to get per invocation with nice naming ;-) Feb 24 11:52:12 strace: [ Process PID=15408 runs in x32 mode. ] - should diffoscope-native/python3-native really be doing that Feb 24 11:54:16 wait what Feb 24 11:54:37 thats terrifying if true Feb 24 11:55:35 rburton: I don't believe it but that is what it says Feb 24 11:56:17 surely file on the binary can tell you Feb 24 11:56:21 python3-native/python3.9: ELF 64-bit LSB shared object Feb 24 11:56:36 so what is strace on about? Feb 24 11:57:37 so googles suggests that x32 detection is a heuristic and can be wrong Feb 24 11:59:08 rburton: ah. its a weird world. gdb is now spewing warnings due to a glibc version it doesn't understand Feb 24 11:59:18 fun! Feb 24 12:03:58 last night i was asking: more specifically, as i understand it, the binutils has to be ported to the processor architecture for which the build is constructed. how is this provided? Feb 24 12:04:16 khem: i saw your response last night but i'm still confused (a common situation) Feb 24 12:04:43 the question above was preceded by this question: pardon me if i've asked this recently, and this is not necessarily a yocto question, but which component of a linux build provides the cross toolchain? Feb 24 12:05:57 so khem the basic question is this: does the cross-binutils first have to be created (copied/stolen from other projects), then provided to yocto, or is there a way somehow for yocto to build it? Feb 24 12:07:05 the problem is that we won't have a prebuilt cross-toolchain for our processor arch. it is custom Feb 24 12:11:09 yates: When you say "custom", is that a fully custom ISA or built around an existing common ISA? Feb 24 12:18:15 fully custom ISA Feb 24 12:21:14 yates: You'll need to port binutils, gcc, etc. Expect to put a couple of person-years of work in if the ISA customisations are non-trivial Feb 24 12:23:02 Typically in Yocto Project we build cross-binutils from source but obviously the binutils source needs to include support for the ISA you're targetting Feb 24 12:24:05 paulbarker: exceellent info. thank you. Feb 24 12:28:34 touch usr/lib/rpm/rpmrc "fixes" the diffoscope hang Feb 24 12:49:05 dl9pf: retesting master-next, hopefully the hang is partly addressed and we have the font issue. I've opened an upstream bug for the diffoscope html hang Feb 24 12:57:07 Hi, i want to create a extra image for the boot partition of a a raspberrypi. The files are packed by wic and bootimg-partition.py. wic creates the FAT image in "${WORKDIR}/build-wic" (of the image recipe), but i need to have an extra image recipe, that deploys the files as a tar.xz Feb 24 12:57:08 Is there any clever way to do this? I tried to strip an image created by image.bbclass but it feels like its too complicated. Feb 24 13:18:14 fl0v0: you don't need an extra image recipe, you need an extra image type (IMAGE_FSTYPES IIRC) Feb 24 13:19:51 qschulz: thanks will look more into the image_types.bbclass then? Feb 24 13:35:18 I'm getting a bunch of "WARNING: SOURCE_DATE_EPOCH value from sstate '0' is deprecated/invalid. Reverting to SOURCE_DATE_EPOCH_FALLBACK '1302044400'" when I build with current master, but there is no indication what recipe are causing them. Will they go away by themselves, or is there something I can do to get rid of them? Feb 24 13:38:36 Is there a means to have multiple seperate layers in a single repository? I see the combo-layer feature, but what I want to do is have a repository that has direct folders of repo/meta-foo, repo/meta-bar and so on. Feb 24 13:43:17 Konsgn: meta-openembedded does this. Feb 24 13:45:15 thanks for that! looks like it's really simple to do Feb 24 13:46:01 RP: huh... interesting. Should that file be packaged by rpm.bb? Feb 24 14:14:55 RP: Ok, finally looking at the SDE stuff Feb 24 14:15:06 what kind of recipe I put in build/workspace with devtool add and when in a meta-layer/recipes-kati/recipe.bb? Feb 24 15:01:16 Saur: this is in master/master-next. it is expected, but no action should be required. Feb 24 15:02:12 dl9pf: Ok, so I guess those messages will go away after things are rebuilt? Feb 24 15:03:17 kayterina: I'm sorry but I do not understand your question, can you rephrase? Feb 24 15:05:17 Saur: should go away over time. Feb 24 15:08:19 a,yes.I have my bash scripts and systemd services to put in an image. I did devtool add and it adds a recipe inside build/workspace. Alternatively, I can make a meta-mylayer and put in there the recipe by hand Feb 24 15:08:31 * a,yes.I have my bash scripts and systemd services I want to put in an image. I did devtool add and it adds a recipe inside build/workspace. Alternatively, I can make a meta-mylayer and put in there the recipe by hand Feb 24 15:11:24 kayterina: devtool is a development tool, ultimately, you want your recipes in your layer and not devtool workspace Feb 24 15:11:38 devtool finish does that for you IIRC Feb 24 15:12:07 aha. Feb 24 15:36:15 JPEW: it is packaged, it wasn't relocating correctly. I've adjusted the wrapper and that is fixed. With SDE I concluded we had to bump the hashequiv version Feb 24 15:43:21 RP: Ok Feb 24 15:43:24 Saur: using hashequiv or not? We should have forced everything to rebuild Feb 24 15:43:49 RP: I have a sort of cleanup patch we can try (or at least discuss) Feb 24 15:43:56 Will post it in a minutes Feb 24 15:43:59 RP: Hashequiv is on, using the server started by bitbake automatically. Feb 24 15:44:01 JPEW: ok, thanks Feb 24 15:44:27 Saur: do you set your own hashequiv_version ? Feb 24 15:44:40 RP: No, not that I know. Feb 24 15:45:22 Saur: then I don't quite understand what happened and why you'd see it. I suppose they might self heal as tasks run Feb 24 15:45:52 (it may need to run do_fetch/unpack on an existing build with SDE=0 before it resets it Feb 24 15:47:42 Ya, that's part of the reason the SDE is exlcuded from task hashes... it's not stable before do_unpack Feb 24 15:48:28 and we might not want to invalidate all existing ... just for the fix away from SDE=0 ... Feb 24 15:49:38 dl9pf: well, I gave in and did Feb 24 15:51:02 RP, dl9pf: Sent an RFC patch for discussion Feb 24 15:52:10 I think we could also add something like: do_configure[vardeps] += "SOURCE_DATE_EPOCH_DEP" which would make all do_configure and beyond re-run when SDE changes Feb 24 15:52:19 JPEW: at a quick glance, I don't think that buys us anything at this point. Feb 24 15:52:46 JPEW: I also really do want the disk SDE to match the variable, its confusing otherwise Feb 24 15:53:13 OK Feb 24 15:53:50 JPEW: and you can't make SOURCE_DATE_EPOCH_DEP work that like as you can't calculate that in advance Feb 24 15:54:33 Err, which part? Feb 24 15:54:58 dl9pf, JPEW: How about we unset SOURCE_DATE_EPOCH for fetch/unpack/patch tasks? Feb 24 15:55:41 RP: Ya.... I was trying to avoid having to list "all the tasks that might run before do_unpack" :/ Feb 24 15:55:49 JPEW: when bitbake parses the metadata we compute the task hashes. You can't know at that point the value SDE will take Feb 24 15:56:04 Hmm, where does that tarball created by uninative-tarball end up? Feb 24 15:56:08 JPEW: well, it is cosmetic and avoids warnings Feb 24 15:56:31 Saur: TMPDIR/sysroots-uninative Feb 24 15:56:31 ^^ which is cosmetic? Feb 24 15:56:48 JPEW: clearing SDE for fetch/unpack/patch Feb 24 15:58:51 Hmm, do we need the warning anymore? Feb 24 15:58:56 RP: I don't seem to have that dir. Is it enough to run `bitbake uninative-tarball` or is there some more magic involved? Feb 24 15:59:55 Saur: that definitely won't help. The build either inserts it up front or does not Feb 24 16:00:15 RP: Huh? Feb 24 16:00:15 JPEW: it is useful to have when things go wrong Feb 24 16:00:53 Saur: uninative is downloaded at the start of a build and extracted/installed before tasks run Feb 24 16:01:27 RP: I know. I'm trying to rebuild the tarball since I want to add to it. Feb 24 16:02:07 Saur: oh, right, then yes you just build it Feb 24 16:02:58 Saur: sorry, I though you meant "where does it end up when installed", not "where does it end up when built" Feb 24 16:03:15 RP: Right, it's the latter I'm looking for... Feb 24 16:03:16 Saur: deploy/sdk Feb 24 16:03:34 Ah, thank you. :) Feb 24 16:17:00 JPEW: I think if you try your patch with the sstatesig tests it will fail if you want an example of how it would break Feb 24 16:17:25 * RP notes the last reproducibility tests didn't hang but failed properly :) Feb 24 16:17:39 dl9pf: if we can figure out the font issue we should be good to enable Feb 24 16:19:31 RP: do you expect both the committer and author to sign the patch off, or the committer alone suffices? Feb 24 16:20:28 vdl: how are you defining committer ? Feb 24 16:22:25 RP: I tried to be smart but keeping my personal address to submit the patch (hence the committer) but still use my company email for the author. Then I ask myself should my committer address, author address, or both sign off the patch. Feb 24 16:23:30 vdl: usually the signoff would match the author for this case Feb 24 16:23:42 It looks like a grey area, especially when both committer and author point to the same person Feb 24 16:23:45 RP: ok. Feb 24 16:24:41 depending on circumstance, I do one or both myself.. depends on where I'm working on the patch and in what context.. Feb 24 16:25:04 RP: you're correct in fact because the committer is dropped anyway when sending a patch via email, only the author and the project maintainer applying the patch (you) remain. Feb 24 16:25:07 if it's in my 100% open source role, I do it on my personal. If it's my 100% work role.. work.. if it's a mix, sometimes I end up signing off with both.. Feb 24 16:25:26 (the both is when I'm playing author [work] and maintainer [open source]) Feb 24 16:26:23 from an history point of view, only the author address matters. From the submitted step point of view, that's a different topic but the information will be lost anyway (which is kinda bad). Feb 24 16:26:45 yup Feb 24 16:27:28 fray: that's my case indeed, authored from work, but submitted on my own, not a company task. Feb 24 16:28:31 git commit --signoff's documentation only states the committer, but it might not be accurate depending on the project. Feb 24 16:34:01 vdl ya, usually when I do that I sign off on both accounts.. since the first is the authorship and I had permissiont o release this.. the second is I have permission to submit this for inclusion.. Feb 24 16:34:13 it's a very gray area, but I try to be consistent for my own commits Feb 24 16:35:22 fray: what you just describe is specific to the agreement terms, but I get the idea. Feb 24 16:36:23 problem is there's no clear distinction in Git yet for the downstream integrator/submitter, who might be different from the author. This guy is lost in the process and replaced with the upstream integrator/committer. Feb 24 16:39:59 friendly reminder: OEHH is today in 4h 20min (https://www.openembedded.org/wiki/Happy_Hours) Feb 24 16:43:15 fray: The only downside is having to commit --amend --author= --signoff every times, but we like well done patches, don't we ;) Feb 24 16:43:17 vdl: if you want the information preserved, you can add both signed-off-by lines Feb 24 16:43:56 vdl: if someone handles the patch in some meaningful way, the practise is to add that signed-off-by Feb 24 16:44:47 vdl: the signed-off-by has a very specific meaning about what you're saying about the patch contents and its origin/license Feb 24 16:45:50 thus hardly bound to the author rather than the submitter I presume Feb 24 16:46:17 so having the author SoB is usually the default Feb 24 16:48:58 Ya.. I consider handing it to myself (as an external participant) as meaningful in many cases.. so thats when I do it Feb 24 16:50:30 vdl: right Feb 24 16:50:40 true. If the company explicitly agreed to submit patches upstream, adding your personal address as the committer isn't necessary anymore I'd say Feb 24 17:02:38 Good afternoon everyone. I have a question regarding the use of ALTERNATIVE_PRIORITY. Feb 24 17:03:52 Can I specify the priority in an image recipe? I have two psplash packages and would like to set the priority for either of them depending on the image. Feb 24 17:04:26 They way it is now, both packages are already installed, but the priority is the same. Feb 24 17:06:06 wooloomooloo: recipe data is local so no, you can't from another recipe (image recipe) change another recipe's data (psplash) Feb 24 17:06:28 you can do logic on your final rootfs in your image recipe though Feb 24 17:07:58 one perhaps messy approach would be a rootfs or image postprocess command to tweak the alternative file Feb 24 17:09:03 another approach would be a firstboot script to call update-alternatives to flip it Feb 24 17:10:21 smurray the prostprocessing is what I had in mind at first, but I was looking for a clearer way. Feb 24 17:13:23 wooloomooloo: another approach that is a bit more complicated would be to use multiconfig, with one config for each target image, overriding the package's ALTERNATIVE_PRIORITY as required Feb 24 17:14:03 wooloomooloo: it's perhaps overkill for this, but it'd work. In theory, just that one package would get rebuilt for the second multiconfig Feb 24 17:14:49 For psplash specifically, where would the priorities be set? If I have two or more splash screen packages, is the only place to set the priorities the bbappend itself? Feb 24 17:15:07 lsg: I've dropped khem's go patches and the ffmpeg ptest patch from -next Feb 24 17:15:30 lsg: the cancelled reproducible failures are handled by changes in -next Feb 24 17:15:41 wooloomooloo: or in local.conf with ALTERNATIVE_PRIORITY_pn-splash = "X" Feb 24 17:17:44 Ah. I was hoping to avoid using local.conf, since that's not under version control. Feb 24 17:19:08 RP ok thanks for the info. Feb 24 17:22:03 wooloomooloo: there are options there, you could have your own local.conf.template in your product layer Feb 24 17:22:36 wooloomooloo: or if you use a tool like kas, add the variable to the yaml definition for the build Feb 24 17:28:10 smurray thanks for the pointers. I'll try using the rootfs postprocessing feature. Feb 24 17:29:00 wooloomooloo: okay, good luck Feb 24 17:38:37 Are recommended packages intended to be installed from an image recipe with IMAGE_INSTALL_append = " ${RRECOMMENDS_systemd}"? Feb 24 17:38:55 (systemd being an example) Feb 24 17:39:01 RP: what issues are you seeing with go patches ? Feb 24 17:42:33 khem: I was trying to defer this to Leo ;-). oe-selftest fails: https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1869 lib32 world fails: https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/3090 Feb 24 17:47:07 RP: https://github.com/golang/dep is being built as part of gotoolchain.oeGoToolchainSelfTest.test_go_dep_build. and that repo is deprecated and archived perhaps we should build something else instead. Ironically go-dep was replaced with go mod so I am expecting it to not build Feb 24 17:47:16 vdl: RRECOMENDS packages will be pulled into images automatically unless that's disabled by setting NO_RECOMMENDATIONS, or a package is listed in BAD_RECOMMENDATIONS Feb 24 17:48:54 smurray: is it the default behavior even for poky-less distros? Feb 24 17:49:15 khem: I'm open to patches to update it to whatever makes sense with the new approach Feb 24 17:52:40 vdl: AFAIK, yes. See https://docs.yoctoproject.org/ref-manual/variables.html#term-NO_RECOMMENDATIONS Feb 24 17:53:56 vdl: I tend to not use deb packaging, so I'm not sure if the caveat there means that recommended packages will just always be installed with deb, but that would be my guess Feb 24 17:57:16 anybody else seeing what looks like weird base64 spam over in #poky or has matrix gone off the wagon for me? Feb 24 17:58:17 smurray: thank you. Unrelated question, would you append systemd-container in the distro conf or the image recipe? Feb 24 17:58:54 RP: I see that we can perhaps fix the test case itself to not use old way of building and still keep building dep as module Feb 24 17:59:05 whats the cmd to reproduce it Feb 24 18:00:05 oe-selftest -r gotoolchain.oeGoToolchainSelfTest.test_go_dep_build Feb 24 18:00:07 khem: oe-selftest -r gotoolchain.oeGoToolchainSelfTest.test_go_dep_build Feb 24 18:00:10 will that dp ? Feb 24 18:00:15 oh ok :) Feb 24 18:01:44 vdl: to add it to an image, you mean? Feb 24 18:02:02 smurray: yes Feb 24 18:02:55 vdl: definitely not in the distro conf ;) Feb 24 18:03:58 smurray: if felt legit to add it to the distro conf if your writing a host distro to manage containers Feb 24 18:05:51 vdl: nothing stops you from doing it, but it's not recommended practice to tweak IMAGE_INSTALL or related variables in the distro conf Feb 24 18:06:29 smurray: in this use case (a distro managing containers), what is the recommended practice? Adding some sorts of suggested/recommended? Feb 24 18:08:00 vdl: if you're aiming for some form of reusability with different images, perhaps defining an image feature that pulls in the desired packages or a packagegroup, or perhaps creating a image bbclass that can be used Feb 24 18:08:46 vdl: if it's for building a dedicated product image that won't be shared, I'd probably just add whatever is required to IMAGE_INSTALL in the image recipe Feb 24 18:09:51 smurray: there's already a "container" image type for the guest systems, so an image "feature" might do the trick. In the meantime maybe just a reference "host" image recipe which can be required is enough. Feb 24 18:10:33 vdl: the issue there is there are many options for what the host can use for running containers Feb 24 18:11:03 * moto-timo currently banging head on podman for instance Feb 24 18:11:57 no docker, just cri-o/cni/podman/runc Feb 24 18:12:01 smurray: sure, I'm kinda forcing the container engine here with my "reference" host distribution Feb 24 18:12:17 moto-timo: Fedora CoreOS? ;-) Feb 24 18:12:29 no Feb 24 18:12:32 Yocto built Feb 24 18:12:47 there's no meta-fedora? damn it! Feb 24 18:13:07 I wouldn't use it anyway. Feb 24 18:13:14 Build from source. you know what you have Feb 24 18:13:33 * vdl was joking obviously Feb 24 18:27:43 RP: https://paste.ubuntu.com/p/3dVJTQcbJv/ does oe-selftest expect poky ? Feb 24 18:40:10 all the cool kids are doing debuginfod, it seems: https://lwn.net/Articles/847256 Feb 24 18:44:01 * vdl isn't cool :-( Feb 24 18:50:11 whats the best method for fixing broken patches? Feb 24 18:54:10 mischief: I'd personally manually apply the bits to the upstream project and regenerate the patch properly. Feb 24 19:23:37 vdl, smurray: about systemd defined in the distro, the doc says to set VIRTUAL-RUNTIME_init_manager, _dev_manager and cie in the distro Feb 24 19:23:41 https://docs.yoctoproject.org/dev-manual/common-tasks.html#selecting-an-initialization-manager Feb 24 19:23:44 Those variables are used in the RDEPENDS of packagegroup-core-boot.bb, which is used in the IMAGE_INSTALL core-image.bbclass Feb 24 19:24:42 (and good night, people :) ) Feb 24 19:24:43 kyanres: that's a bit out of date, now you'd set INIT_MANAGER = "systemd" Feb 24 19:27:03 ah, thanks, I'll try to use that Feb 24 19:44:41 smurray: a patch was actually applied to update this part of the doc ;-) Feb 24 19:47:03 vdl: I see it mentioned in the zeus migration notes, the common tasks docs could stand to be updated, I think Feb 24 19:49:04 smurray: I've only updated meta-poky/conf/local.conf.sample.extended Feb 24 20:01:58 o/ Currently trying to deal with a hanging build. My coworker and I setup ubuntu virtual machine on our macs. Installed requirements, and I tried to get kas to start on our kas.yml in the VM. Feb 24 20:02:16 Things look decent, but on one of the first steps, I'm having heaps of trouble getting bitbake to pull down its deps, and I can't seem to build core-image-sato without my VM spinning forever and failing to make progress after downloading a couple of things. Feb 24 20:03:06 I'm guessing that the trouble is NOT going to be inside kas, bitbake, or yocto as a whole in any capacity... and most likely some issue with the virtual machine I setup... Feb 24 20:03:51 I'd love to pry further, just need to know where to go for questions, or how to debug further... as the log just sort of indicates that it's trying to download sources, and then stalls after 20-30 minutes Feb 24 20:28:44 Spooster: start with a non-virtual machine, really. yocto is a beast to compile and virtualization only takes performance away and doesn't give you anything. Maybe the device is out of RAM and swapping like hell Feb 24 20:32:37 not a terrible idea... Feb 24 20:44:05 we're on mac... so getting things running natively seemed like too much of a bother Feb 24 20:44:10 but obviously this isn't much better Feb 24 20:55:51 OEHH in 5 minutes :-) Feb 24 20:56:01 https://www.openembedded.org/wiki/Happy_Hours Feb 24 20:56:39 khem: we test it with poky... Feb 24 21:25:14 haha! it should have been this obvious, but in our morning haste, before the coffee hit, we setup a two different VM's trying to get things identical... and I forgot to double check allocated memory for the second one we built that we wanted to continue using... so it was indeed doing it's best on 1G ram, and dying to swap... Feb 24 21:25:33 @mcfr Feb 24 21:25:46 astounding guess +1 Feb 24 21:28:33 RP: rpm macros: %__font_provides /usr/lib/rpm/fontconfig.prov Feb 24 21:28:42 we could try and define this as %{nil} Feb 24 21:33:03 RP: do you know if there's a summary of the yocto development process somewhere? I know there are multiple wiki pages and the like, but I'm looking for a summary/intro Feb 24 21:33:11 figured i'd check before i write something Feb 24 21:39:17 RP: package_rpm.bbclass: add cmd = cmd + " --define '__font_requires %{nil}'" ? Feb 24 21:40:00 I'd need to see what the expansion is of ${_rpmconfigdir} for rpm-native when invoked Feb 24 21:43:18 kergoth: not sure if the testing manual has anything? If you do write something please share as I'd like to improve this kind of thing in the manuals if we don't cover it Feb 24 21:44:11 dl9pf: rpmconfigdir should be set correctly to the sysroot Feb 24 21:44:50 dl9pf: happy to try adding that to package_rpm and see what happens Feb 24 21:45:33 wait a few min ... let me take a look Feb 24 21:46:22 ok, here is the catch: Feb 24 21:46:41 tmp/sysroots-components/x86_64/rpm-native/usr/lib/rpm/fontconfig.prov Feb 24 21:46:50 contains: fcquery=/usr/bin/fc-query Feb 24 21:46:57 that will call into $HOST Feb 24 21:47:38 either we nuke calling it at all (see above) or we need to depend on fontconfig-native and mange that call Feb 24 21:47:56 dl9pf: lets just remove that Feb 24 21:49:22 ok, then please try --define '__font_requires %{nil}' Feb 24 21:49:37 ok, then please try --define '__font_provides %{nil}' <<<<<<<<<<<<<<<<< Feb 24 21:52:55 dl9pf: I've hacked something into master-next Feb 24 22:02:37 With meson how do I force a result for find_program() ? Feb 24 22:09:19 RP: I have sent an update for seltest for go toolchain hope that helps Feb 24 22:19:13 hello I try to use useradd.example.bb frm skeleton . .. do I have to put username1 in file1 username2 in file2 ? a,d adjust number of file1 file2 ? Feb 24 22:28:01 hello Feb 24 22:29:34 hrm... Feb 24 22:29:59 im trying to upgrade to gatesgarth and for some reason gcc can't find libzstd Feb 24 22:31:52 which architecture? Feb 24 22:32:32 I'm trying to create custom distro for my raspberrypi3 using yocto but during development I want to use qemu emulator. Feb 24 22:32:32 To run qemu emulator I'm using following command: sudo qemu-system-arm -kernel /home/ppavacic/Downloads/qemu-rpi-kernel/kernel-qemu-4.4.34-jessie -cpu arm1176 -m 256 -M versatilepb -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" rpi-basic-image-raspberrypi3-20210224212727.rootfs.rpi-sdimg -no-reboot Feb 24 22:32:33 Where kernel argument is kernel downloaded from this git: "ttps://github.com/dhruvvyas90/qemu-rpi-kernel" Feb 24 22:32:56 If you setup the files proeprly you can use 'runqemu' and it'll do all of the configuration for you Feb 24 22:34:49 so your suggestion is to just change machine type to qemu? Feb 24 22:34:52 qemuarm Feb 24 22:35:17 fray: targetting arm building on x86 Feb 24 22:35:28 ppavacic: no, the rpi machine can set the right variables so runqemu just works Feb 24 22:35:30 you CAN do that, or you can create (or re-use) a rpi machine configuration that has QEMU enabled.. Feb 24 22:35:40 assuming qemu can emulate an rpi sufficiently Feb 24 22:35:41 it's all down to the machine confgiuration Feb 24 22:35:49 yes, as rburton said Feb 24 22:37:44 well qemu works perfectly for raspbian Feb 24 22:37:59 tthats official distro of rpi Feb 24 22:39:03 so find out what qemu flags they recommend, then add them the rpi machine file (qemuarm.conf is a good start, all the QB_* variables). Then every image will also build a qemuboot file, and you can just runqemu Feb 24 22:39:17 .. now configure zlib behaving weird: | Compiler error reporting is too harsh for ./configure (perhaps remove -Werror). Feb 24 22:39:22 never seen that before. Feb 24 22:40:25 ya, look at meta/conf/machine/qemuarm.conf (or qemuarm64 if it's a 64-bit capable rpi) the variables QB_* all list how to configure/execute qemu Feb 24 22:40:36 this is what 'runqemu' uses to manage everything Feb 24 22:41:58 this tutorial says that the easiest way is to just build with qemuarm64 as machine so that artifacts are prebuilt Feb 24 22:46:48 there is getting started, and then there is going beyond that.. for getting started we recommend using qemu* machines.. once you go beyond that, then finding someone else who has already created an rpi configuration or creating one yourself is the next step Feb 24 22:47:40 you don't have to use the Yocto Project kernel sources, you can use raspbian if you really want.. but using the YP tooling for compilation, qemu, etc will be much easier and then other docs and tutorials can be done Feb 24 22:51:03 khem: did you fix the lib32 issue? Feb 24 22:51:12 (for go) Feb 24 22:53:08 okay thanks! i will start with basic qemu machine Feb 24 23:55:49 RP: I fixed the selftest I thought that was primary issue ? Feb 24 23:56:02 btw. I am seing https://paste.ubuntu.com/p/34Jvhbccdp/ today did something change ? Feb 24 23:57:53 khem: two issues, second is https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/3090 Feb 24 23:58:20 khem: I don't think I did anything to cause that Feb 24 23:58:55 hmm I wonder whats going on I rebooted the build machine and also rebuilt qemu-native Feb 25 00:02:57 ah unsupported setting GO386=387. Consider using GO386=softfloat instead. Feb 25 00:03:08 which is true for go 1.16 387 is dropped Feb 25 00:05:04 khem: sounds like a straightforward reconfig hopefully? Feb 25 00:05:15 see https://github.com/golang/go/issues/40255 Feb 25 00:05:18 thanks for the other fix btw, I have put that one into new testing Feb 25 00:06:09 khem: hopefully our minimum commonly used tunes are SSE2 Feb 25 00:06:38 * RP -> sleep Feb 25 00:06:48 yeah I sent a untested patch to ml Feb 25 00:07:13 you can pick the two I sent today on top of go ones from yesterday before bed :) Feb 25 00:16:40 RP: I think DEFAULTTUNE_virtclass-multilib-lib32 = 'x86' Feb 25 00:16:40 should be DEFAULTTUNE_virtclass-multilib-lib32 = 'core2' perhaps in the test builds Feb 25 00:22:01 or perhaps core2-32 is right value Feb 25 00:27:06 hrmmmm Feb 25 00:27:15 i wonder if my compiler issue is due to icecc. Feb 25 00:29:35 aha! Feb 25 00:43:53 yes, something is wrong with icecc... at least with gatesgarth on ubuntu 20.04 Feb 25 00:44:05 the zstd library is captured incorrectly **** ENDING LOGGING AT Thu Feb 25 02:59:57 2021