**** BEGIN LOGGING AT Fri Sep 20 02:59:57 2019 Sep 20 04:54:13 I'm having problems getting Yocto to use my .bbappend file. I'm trying to use a .bbappend for u-boot, and in my build u-boot is provided by a recipe called u-boot-variscite. So in my own layer I have created recipes-bsp/u-boot/u-boot-variscite.bbappend. But if I run bitbake-layers show-append | grep u-boot it does not show up. My layer is in "bitbake-layers show-layers", and *.bbappend is in the BBFILES in Sep 20 04:54:26 my layer.conf (I have other .bbappends in the same layer that are recognized). Sep 20 04:58:30 iceaway: does the .bb have a version? does your .bbappend have a version? (aka u-boot-variscite_.bb) Sep 20 05:02:33 nrossi: Nope, the .bb is just u-boot-variscite.bb. I actually had this working and what caught me then was that I called my .bbappend u-boot-varicite_%.bbappend, and then it would list as "skipped". But then for some reason I deleted the whole .bbappend stuff and had to start over, and now it's not listed at all. Sep 20 05:04:46 as long as your layer is in bblayers and the bbappend is in bbfiles, and the filename exactly matches (with % wildcards) the .bb filename, it'll be applied Sep 20 05:04:52 i'd check each of those systematically. Sep 20 05:05:21 most common when i run into this it's something stupid like accidentally putting it in the root of recipes-whatever/ instead of in the recipe subdir, or the filename has a typo relative to the .bb Sep 20 05:06:27 I have triple-checked all those, but will check again. It is also my experience that when you eventually find the error it was some stupid typo or similar that you just were incapable of seeing. Sep 20 05:07:11 also make sure BBMASK isn't interfering. it's highly unlikely, but possible Sep 20 05:08:04 it does not really matter what the directory under recipes-bsp/ is called, right? Bitbake will search all dirs (if configured so in layer.conf) and match by .bb/bbappend right? Sep 20 05:09:07 i.e. it could be meta-bsp/foobar/u-boot-variscite.bbappend? Sep 20 05:09:39 iceaway: only if your BBFILES patterns allows it to match, e.g. with a BBFILES entries of "recipes-bsp/*/*.bb recipes-bsp/*/*.bbappend" Sep 20 05:10:21 nrossi: great :) Sep 20 05:10:58 kergoth: Thanks for the BBMASK hint. I had forgotten that I tried to disable my u-boot.bbappend yesterday by adding a BBMASK in my local.conf for u-boot! *facepalm* Sep 20 05:12:22 heh, np, that'd do it Sep 20 05:12:41 as nrossi says, the layout is up to you, as long as BBFILES matches it, you're fine Sep 20 05:20:02 kergoth, in bitbake, do you know if it is true in general that during variable expansion, all overrides are applied before all _append/_prepend/_remove are applied ? Sep 20 05:49:02 kroon: just looking at bitbake code itself, looks like overrides are processed before _append/etc. see here: https://git.openembedded.org/bitbake/tree/lib/bb/data_smart.py#n734 Sep 20 05:52:43 nrossi, thanks! Sep 20 07:19:52 <__angelo> hello ! in an initramfs for arm i miss all devices, so getting spam of tty missing, is there any link in the manual to setup this ?^ Sep 20 07:20:51 <__angelo> (i only have /dev/console) Sep 20 07:25:02 Hello, I have a problem loading a kernel module at boot, I would like to load i2c-dev so I added KERNEL_MODULE_AUTOLOAD += "i2c-dev" in my local.conf and nothing happens, any idea why ? (I can load the module when connected to the machine with "modprobe i2c-dev"...) Sep 20 07:45:24 kroon: its not as simple as "before" or "after", it depends on the expression Sep 20 07:45:54 kroon: X_append_override is override first, X_override_append is append first. Its basically right hand side first Sep 20 07:48:24 RP, hmm ok. and for X_append + X_override, it is override first ? Sep 20 07:48:57 kroon: no, overrides tend to win over appends in a straight head to head Sep 20 07:56:12 RP, initial testing here with bitbake master would indicate that for X_append + X_override, it is override first, then append is applied.. Sep 20 07:57:11 RP, is there an easy explanation for when overrides would win ? Sep 20 07:57:35 in the case above I mean Sep 20 07:58:38 kroon: I'm clearly confused and append does win Sep 20 07:59:02 kroon: sorry, I'm misremembering Sep 20 07:59:17 RP, ah Sep 20 07:59:20 kroon: the rules are clearly defined with the test cases in bitbake Sep 20 07:59:46 good point Sep 20 08:14:36 kroon: I think you can remember it like that: X_append is a desire to append to X whatever the override is. X_override override X for override only. If _append would be prioritized over _override, it would mean that _append is a desire to append only to default conf and everyone would need to add _override to X to be sure X is appended for every cases => impossible to maintain Sep 20 08:43:02 New news from stackoverflow: How to get OpenCV 4.1.0 on the yocto/poky warrior branch? || Rescue partition in Yocto image **** BEGIN LOGGING AT Fri Sep 20 09:14:43 2019 Sep 20 11:13:23 New news from stackoverflow: How to reduce the Jetson Nano .sdcard flash file size? Sep 20 11:30:23 how to add a line in inittab file? the sysvinit-inittab_ append is not read. Sep 20 11:32:05 I add the line in do_install_aooend in sysvinit-inittab_2.88dsf.bbappend Sep 20 11:33:35 kayterina: 1. are you sure the bbappend is applied? 2. which file are you modifying? the one in your workdir/builddir/sourcedir or the one that is installed in ${D}? Sep 20 11:34:20 I am fairly sure it is not applied. Sep 20 11:34:53 I added /mylayer/reciped-core/sysvinit/sysvinit-inittab/sysvinit-inittab_2.88dsf.bbappend Sep 20 11:35:00 I saw it in SO Sep 20 11:35:06 *read Sep 20 11:37:10 qschulz: I modify the file in {D}, as I have ${D}${sysconfdir}/inittab Sep 20 11:38:21 * kayterina sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/wcTZZyPjsUlnljlyQtgmQEDr > Sep 20 11:44:54 kayterina: reciped-core or recipes-core? Sep 20 11:45:04 recipes Sep 20 11:45:15 you have one too many subdirs Sep 20 11:45:44 recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bbappend Sep 20 11:45:50 that's where it should be Sep 20 11:46:48 it is there. Sep 20 11:46:59 sorry I didn't copy-paste Sep 20 11:47:09 (the path where bitbake looks for bb or bbappend is BBFILES in conf/layer.conf of your layer) Sep 20 11:47:47 could it be a priority issue? when is inittab created Sep 20 11:47:56 my layer is priority 6 Sep 20 11:50:04 kayterina: you can check the bbappend is detected by using bitbake-layers show-appends sysvinit-inittab AFAIR Sep 20 11:50:35 @qschulz ok,I'll do that, thanks Sep 20 11:51:37 then, if it's correctly parsed, you can check the actual value of do_install (in order as it will be executed) in $WORKDIR/temp/run.do_install Sep 20 11:52:16 this is basically what is executed by bitbake, so you can see the order of things. Sep 20 11:57:32 if you're just providing a new file, i don't think you need to even do do_install_append Sep 20 11:57:51 rburton: kayterina is echo-ing >> to it Sep 20 11:58:04 ah ok ignore me Sep 20 11:58:58 well, I don't have a do.run_install in workdir Sep 20 12:03:01 run.do_install? Sep 20 12:03:12 in the workdir of the recipe? Sep 20 12:09:40 inside the $WORKDIR/temp Sep 20 12:13:44 what is $WORKDIR exactly for you? Sep 20 12:14:23 it is the image dir I think? I grep'd it Sep 20 12:14:38 I meant the workdir of the recipe Sep 20 12:14:42 bitbake -e dikomoy-image-minimal |grep ^WORKDIR= Sep 20 12:14:49 Ah, no :) that does not work Sep 20 12:15:05 well.. yes it does but it's the workdir of the image recipe not the sysvinit-inittab recipe Sep 20 12:15:32 so you could technically do the same but with bitbake -e sysvinit-inittab | grep ^WORKDIR= Sep 20 12:15:34 it finds non existant directory with sysvinit-inittab Sep 20 12:15:50 but since you already know bitbake -e, you cand irectly look at do_install in there Sep 20 12:17:18 kayterina: have you cleaned your workdir since last build? are you using the same MACHINE and DISTRO for bitbake -e sysvinit-inittab than when you built your image? Sep 20 12:18:56 I am using the same MACHINE and DISTRO, I did change some things,then rempved,then built Sep 20 12:19:09 perhaos I'll just rm tmp and rebuild,is it correct? Sep 20 12:21:09 just bitbake sysvinit-inittab Sep 20 12:21:18 ok Sep 20 12:21:49 then after it's done, the dir mentioned in WORKDIR should be there Sep 20 12:27:33 JPEW: I've put some fixes in -next for testing Sep 20 12:39:37 RP: any idea how a usergroup from recipea can be used in useradd from recipeb? we have some occurences when this fails (we depends/rdepends in recipeb on recipea) Sep 20 12:40:22 qschulz: I think there are open bugs for this filed by Tartarus Sep 20 12:40:38 qschulz: adding the user in both recipes is the workaround right now Sep 20 12:40:54 I've not had the bandwidth to figure out a better fix Sep 20 12:40:55 in our case the group then :) Sep 20 12:41:11 qschulz: right, same thing Sep 20 12:41:16 RP: do you have a link by any chance? Sep 20 12:42:25 qschulz: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13419 Sep 20 12:42:26 Bug 13419: normal, Medium+, 2.8 M3, richard.purdie, NEW , recipes that add users to groups cannot rely on other recipes creating those groups (when population from sstate happens) Sep 20 12:42:36 https://bugzilla.yoctoproject.org/show_bug.cgi?id=13279 Sep 20 12:42:37 Bug 13279: normal, Medium+, 2.8 M3, liezhi.yang, NEW , Make sure users/groups exist for package_write_* tasks Sep 20 12:49:21 RP: thanks! we'll try the workaround Sep 20 12:50:57 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/178 issustrates what I think is the remaining hashequiv runqueue problem Sep 20 12:53:15 OK, good, I'm not filing bugs about stuff in my sleep ;) Sep 20 13:02:04 RP: fyi. Still digging down in the freezer cgroups for strace fun. At least I'll be able to discuss it fully on the mailing list if I fail to fix it. Sep 20 13:03:25 zeddii: ok, cool. I was wondering how that was going Sep 20 13:04:34 RP (or anyone else) while the kernel builds yet again .. if I made bad design decision several years back and made variants of a recipe/package without using virtual/foo ... is there any graceful way to switch to virtual/foo now ? without breaking existing DEPENDS/RDEPENDS ? or am I stuck with a flag day kind of change ? Sep 20 13:06:56 zeddii: well, you can still add PROVIDES = "virtual/" it won't change what exists currently AFAIK? Sep 20 13:08:44 zeddii: I'd have thought you could add in extra PROVIDES Sep 20 13:11:14 I haven't run all the tests yet, but since it wasn't virtual/foo before, won't anyone that had depends=foo, etc, break if I switch everything to virtual/foo ? maybe I just need more coffee. I want to move it to a preferred provider kind of thing, so now that I think about it, the *packages* will be the same so image_install, etc are fine, it is just depends. Sep 20 13:11:54 but yah. with the extra provides it should be fine Sep 20 13:11:58 * zeddii tries that. Sep 20 13:13:30 zeddii: virtual/X is a DEPENDS only namespace and a recipe can PROVIDE more than one thing Sep 20 13:13:37 yah Sep 20 13:13:46 I realized that after typing it out :D Sep 20 13:14:00 you can't IMAGE_INSTALL = "virtual/kernel" :D Sep 20 13:27:56 RP: ok, quick question :) apparently the user/group dependency between two recipes bug does not happen if we have 'deltask do_package_setscene' in the recipe depending on the other recipe. Is this wrong? On which level of wrongness are we :) ? Sep 20 13:30:56 qschulz: that doesn't sound right to me Sep 20 13:51:15 RP: It runs the do_configure/do_compile etc. without running do_fetch? Sep 20 14:01:41 JPEW: yes :/ Sep 20 14:02:00 JPEW: basically it setscened all the tasks for that recipe, then decided it really needed to rerun them Sep 20 14:07:42 qschulz: is inittab provided by sysvinit-inittab for raspberry pi? Sep 20 14:09:26 in sysvinitab workdir there is the inittab with my append but it is different from the one in the image Sep 20 14:10:11 kayterina: https://wiki.yoctoproject.org/wiki/Technical_FAQ#How_do_I_find_out_which_package_contains_a_particular_file_.28or_python_module.29.3F Sep 20 14:10:17 this could help maybe? Sep 20 14:10:25 RP: Hmm.... interesting. Sep 20 14:28:21 JPEW: Its a tricky dilemma on how to handle this :/ Sep 20 14:28:44 RP: Ya, I agree.... is there any indication as to why it though those needed to be rerun? Sep 20 14:30:50 JPEW: the hash of a dependency changed to one which was no longer compatible Sep 20 14:31:42 JPEW: the setscene had already run, it then decided to change the hash and turn it to a normal task as there was no sstate Sep 20 14:32:07 JPEW: we could make it so that once setscene has run, the hashes can't change Sep 20 14:34:23 RP: Is any of the setsecene it did for adwaita-icon-theme valid? Sep 20 14:34:40 JPEW: it was valid, then new hashes appeared Sep 20 14:34:49 no longer matched Sep 20 14:39:13 RP: I guess I'm not quite following where that happened. gtk+ do_populate_sysroot was detected as equivalent and it's unihash was updated. This caused a cascade of setsecene tasks to be re-run, then adawait-icon-theme started rerunning. Wheres the hash that no longer matched? Is it one of the other tasks that setsecene'd after gtk+ changed? Sep 20 14:39:31 We're trying to move to pigz for opkg packages compression but it fails if I don't have pigz in my host Sep 20 14:39:47 OPKGBUILDCMD = "opkg-build -Z pigz" Sep 20 14:40:29 qschulz: yes, that's right. that's exactly what would happen if you did that. Sep 20 14:40:43 would it make sense to add DEPENDS = "pigz-native" to opkg-utils? Sep 20 14:40:47 no Sep 20 14:40:50 yup Sep 20 14:40:54 see pacakge_ipk.bbclass Sep 20 14:41:05 which in case, uses multithreaded xz and thus depends on xz-native Sep 20 14:41:12 JPEW: after the gtk rehash it prints that adwaita-icon-theme changed (multiple tasks) Sep 20 14:41:14 "which in master", even Sep 20 14:41:28 JPEW: that meant the previous setscene was invalid and it now needed to rerun the adwaita-icon-theme tasks Sep 20 14:43:16 rburton: mmm, I'm lost now :/ Sep 20 14:43:37 RP: Just to make sure I'm on the same page, what line of the log file is that? Sep 20 14:44:12 JPEW: 9139 is where it says its rerunning adwaita-icon-theme Sep 20 14:45:06 rburton: is there a way to add pigz-native dependency to the build? Sep 20 14:45:27 qschulz: yes, see package_ipg.bbclass which in master does exactly that for xz Sep 20 14:46:29 I need to override this class then, right? Sep 20 14:46:48 you can replicate the logic in another class Sep 20 14:47:45 i recommend xz over pigz, better control over usage in heavy builds Sep 20 14:48:08 wdym? Sep 20 14:48:22 our concern at the moment is to make the build faster basically Sep 20 14:48:45 left to its own devices a heavily parallel build can end up getting OOMd, xz lets you control memory usage and threading nicely Sep 20 14:48:51 which is why its used in oe-core master Sep 20 14:49:46 warrior has that too Sep 20 14:49:54 so consider just upgrading :) Sep 20 14:51:09 "warrior has that too"? Sep 20 14:51:16 the use of threaded xz Sep 20 14:51:38 because thud does not have it? Sep 20 14:51:54 (sorry for the dumb questions, brain is fried for this week) Sep 20 14:52:29 hm no thud has xz too, just doesn't control its memory usage Sep 20 14:52:34 OPKGBUILDCMD ??= "opkg-build -Z xz" Sep 20 14:53:07 so you can easily tweak opkg-build to do a multithreaded xz Sep 20 14:54:18 you might want to backport https://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/commit/opkg-build?id=49d32419abec4142995f3ed6f840137c8a72f3b3 then you're happy Sep 20 14:56:20 RP: oh my api-doc world thing didn't land, so i shouldn't feel bad :) Sep 20 14:56:38 rburton: no, not yet. Enough other moving bits Sep 20 14:57:00 well i have a tweak to make it exclude webkitgtk to save half an hour :) Sep 20 14:57:27 rburton: ok, cool Sep 20 14:57:40 rburton: autobuilder helper change? Sep 20 14:57:44 yes Sep 20 14:57:48 ross/gtkdoc in the repo Sep 20 14:58:03 RP: Shouldn't the setsecene tasks being eligible to run have covered the other tasks (do_configure/do_compile?). The setscene tasks became valid, but didn't actually rerun? Sep 20 15:00:12 JPEW: Its do_populate_lic that complicated things, that was still valid Sep 20 15:00:25 (and depends on tasks pre configure) Sep 20 15:01:07 RP: Ok, that makes sense Sep 20 15:02:31 RP: Out of curiosity, how do you know it was that task? Sep 20 15:03:57 JPEW: I just recognise the patterns Sep 20 15:04:31 JPEW: populate_lic is nearly always reused from sstate as it only depends on the sources Sep 20 15:05:04 RP: I figured :) Looking at a lot of these logs gives a good feel for what should be running Sep 20 15:09:00 RP: Ok, so if that is the case, why didn't do_fetch run? My guess: Already had a stamp file for do_fetch from a previous run, so it started from the first task that actually changed (do_prepare_recipe_sysroot), but the fetch wasn't actually there because... a previous setsecene task invalidated it? Sep 20 15:09:22 JPEW: that isn't what I think happened Sep 20 15:10:16 JPEW: I think all of adwaita-icon-theme came from sstate originally so the build marked many of the tasks as skipped Sep 20 15:10:32 when the hashes changed, its having trouble "unskipping" tasks which became buildable Sep 20 15:11:05 RP: OK, that makes sense Sep 20 15:11:51 JPEW: adwaita-icon-theme:do_patch is buildable before gtk+ populate_sysroot completes Sep 20 15:12:15 JPEW: I think the answer is going to be not to rerun sstate tasks once they've run. What that means for the sigs I don't know though Sep 20 15:16:07 * JPEW finds a whiteboard.... Sep 20 15:27:17 RP: How do you know do_patch was buildable? Sep 20 15:27:44 JPEW: I'm guessing a bit :/ Sep 20 15:27:56 JPEW: I've spent a long time staring at the code Sep 20 15:28:08 JPEW: I can't explain it any other way Sep 20 15:28:23 RP: You have bitbake ESP Sep 20 15:29:04 JPEW: More like spent the day on this :( Sep 20 15:29:24 JPEW: I'm open to others ways to explain why it breaks Sep 20 15:31:06 JPEW: we could try http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=c679b56e8b4895f926f6bfb73fcf08c61a78f90b Sep 20 15:31:44 JPEW: for determinism we may want to have a report_unihash there Sep 20 15:32:11 JPEW: not sure what we can use as outhash as we don't have one Sep 20 15:36:59 RP: Hmm..... perhaps worth a try, but I'm not sure it's quite the right thing. Sep 20 15:36:59 rburton: I don't understand why DEPENDS = "pigz-native" in opkg-utils-native wouldn't work (I'm not saying it's the good way to do it, I just want to understand) Sep 20 15:37:06 RP: How reproducible is this? Sep 20 15:38:20 it's going to put pigz-native:do_populate_sysroot as a dependency of opkg-utils-native:do_configure which happens before do_package_write_ipk right? Sep 20 15:38:24 JPEW: happens on the autobuilder in 2-3 builds? Sep 20 15:38:42 or is it not ideal because it installs everything to a sysroot that we shouldn't need? Sep 20 15:39:17 qschulz: it might work but opkg-utils doesn't depend on it so its technically wrong Sep 20 15:39:47 JPEW: I don't like this but I can't see another way for things to work Sep 20 15:39:48 RP: such an idiot... Sep 20 15:40:21 RP: BTW, RDEPENDS for a native package should work in master now? because I guess that's what should be needed right>? Sep 20 15:42:08 qschulz: it kinds of works Sep 20 15:42:22 qschulz: think about how RDEPENDS works when PACKAGES="" Sep 20 15:42:32 (which is why its 'fun') Sep 20 15:44:15 RP: I saw that test in package_ipk.bbclass, when does this happen? Sep 20 15:44:20 in images? Sep 20 15:47:42 qschulz: when does what happen? Sorry but I really need to concentrate on other things :/ Sep 20 15:50:30 qschulz: package-ipk.bbclass shows exactly how to add dependencies for packaging Sep 20 15:50:32 RP: PACKAGES="". no worries, it's just curiosity :) Sep 20 15:51:20 qschulz: native.bbclass Sep 20 15:51:49 https://github.com/openembedded/openembedded-core/blob/master/meta/classes/package_ipk.bbclass#L261 if you're having trouble Sep 20 15:52:13 rburton: there are many ways to do different things. I saw how it's done in package_ipk.bbclass, I wanted to know if other ways I thought of could work as well and if and why it shouldn't be used. Sep 20 15:52:25 what the class does is the one way Sep 20 15:52:39 do bitbake files have issues with HEREDOC in bash functions? Sep 20 15:52:55 rburton: well, PACKAGE_WRITE_DEPS in conf/local.conf is another way Sep 20 15:53:36 marler899763: our parser may Sep 20 15:53:41 qschulz: fails if you need the thing to build the thing Sep 20 15:56:46 marler899763: there's a few recipes in the AGL layers that use here documents Sep 20 15:57:11 I'm guessing HEREDOC works so long as you don't use certain characters Sep 20 16:03:57 rburton: *facepalm*, that's what I get for trying to be smart on a Friday afternoon Sep 20 16:09:11 rburton: I'm very curious now why it didn't fail when we compiled with PACKAGE_WRITE_DEPS = "pigz-native". What's in package_ipk.bbclass in the very same line you sent is doing the same as if PACKAGE_WRITE_DEPS was "xz-native". Or am I being an idiot again abd it's really time to go home? Sep 20 16:19:59 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/389 step1d looks "fun" :( Sep 20 16:25:47 hello all Sep 20 16:25:56 I've just found out about the "Ostro" Operating system Sep 20 16:26:02 it's now dead. why was it abandoned? Sep 20 16:26:55 hm what one was ostro Sep 20 16:27:19 rburton: its bad when you can't even remember! Sep 20 16:27:20 was that the nokia collab? Sep 20 16:27:34 rburton. its that's steaming, burning wreckage on the side of the raod. Sep 20 16:27:35 no, it wasn't Sep 20 16:27:37 i just read about it in https://elinux.org/images/6/69/Demystifying_Systemd.pdf Sep 20 16:27:55 litb: abandoned for boring business reasons Sep 20 16:27:58 apparently it's an operating system for embedded, based on yocto Sep 20 16:28:03 rburton, oh hmm Sep 20 16:28:17 rburton: Ostro was the YP based embedded distro one iirc? Sep 20 16:28:19 the layers are still online Sep 20 16:28:20 yeah Sep 20 16:28:24 maybe we could use it to build our own Sep 20 16:28:37 'be inspired by it', the layers are untouched Sep 20 16:28:49 and it was a lot of reshashed and recycled failed design ideas ;) Sep 20 16:28:50 iot refkit is similar idea but a bit more recent Sep 20 16:28:52 currently we are trying to figure out how to make our firmware app boot up using systemd Sep 20 16:29:12 litb: well, surely that's just turning on systemd: two lines in your distro conf Sep 20 16:29:34 we want to support multiple app-instances of our firmware on a single device, and want to be able to tell systemd "boot our firmware that's below /firmware1" and "boot our firmware that's below /firmware2" Sep 20 16:29:45 rburton: its one isn't it? Sep 20 16:29:54 RP: i was including setting distro features Sep 20 16:29:59 I'm currently figuring out how to do that. i.e how to put systemd unit files somewhere else than /etc and make systemd use it. Sep 20 16:30:06 rburton: INIT_MANAGER = ? Sep 20 16:30:13 litb: for what you want, ostro isn't relevant. you're talking about general systemd use. Sep 20 16:31:09 rburton, but because we need to still figure out what initrd system to use, what splash screen to use etc.. maybe we could use an existing yocto-based OS that has all of it "solved" Sep 20 16:31:36 litb: if you're using systemd then i believe you don't have a choice for splash Sep 20 16:31:56 psplash and systemd don't get on well iirc Sep 20 16:32:24 currently i use yocto's init framework for initramfs. and systemd as /sbin/init Sep 20 16:32:33 for splash i use plymouth Sep 20 16:33:33 right, solved then :) Sep 20 16:33:41 also I'm not using grub as my boot manager, because yocto/oe doesn't provide ready to use wic scripts for grub+bios Sep 20 16:33:59 so i have to use syslinux currently and need to figure out the steps to install grub later Sep 20 16:34:29 eww bios :) Sep 20 16:38:30 rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/388 is a master failure - don't understand how/why :( Sep 20 17:18:28 RP: Got it. Will raise a bug. Fortunately, it looks like I can reproduce that one locally if I run the test enough times. Sep 20 17:26:04 ugh...ran out of disk space again Sep 20 17:26:48 You would think 500 GB would be big enough for 4 yocto builds... Sep 20 18:00:01 RP: uim failure is due to parallel install race Sep 20 18:00:29 I have pushed a potential fix lets see if that works then we will be green on that tumbleweed box Sep 20 18:47:47 How can I make yocto generate a vmlinuz file? Sep 20 18:56:17 i'm confused about kernel module recipe/package naming.. i have a recipe that makes a kernel module foo.ko, but adding kernel-module-foo to MACHINE_ESSENTIAL_EXTRA_RDEPENDS causes bitbake to say it can't find the package. what's the deal? Sep 20 18:56:39 I get a tar.gz of the filesystem and an Image file containing the kernel, but no vmlinuz. Sep 20 18:58:46 ecdhe: what do you think Image is? :) Sep 20 18:59:18 ecdhe: look at KERNEL_IMAGETYPE in the yocto manual.. 'make help' in the kernel tree and looking at the kernel bbclasses can also be instructive Sep 20 19:02:58 thanks mischief. `file Image' didn't give me any useful information for converting Image -> vmlinuz. I did try gzipping it but it didn't pass the mustard Sep 20 20:18:56 hmm,. no man pages in non-gplv3 due to man-db.. seems like mandoc will do the job, though.. Sep 20 21:41:27 khem: ok, sounds like you're close to sorting it! :) Sep 20 21:41:46 JPEW: I'll leave that one with you then, thanks Sep 21 01:08:28 RP: finally !! https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/17 **** ENDING LOGGING AT Sat Sep 21 03:00:00 2019