**** BEGIN LOGGING AT Tue Apr 09 03:00:03 2019 Apr 09 03:23:19 aehs29. are there variables being constructed and then expanded ? Apr 09 07:08:19 aehs29: I wouldn't trust anything I did back in 2007 :) Apr 09 07:08:38 aehs29: (I don't remember) Apr 09 07:08:49 RP: i wouldn't trust anything i did 5minutes ago Apr 09 07:26:18 Hi, yocto also builds u-boot but it's not enough because I also must use tools like 'mfg' or 'uuu' to build a bootable image. First, is it supported by yocto? Second, if yes, where are its config files? Apr 09 07:26:56 fbre: well you already asked yesterday. it is supported just the same it is in u-boot Apr 09 07:27:28 fbre: so if a specific u-boot configuration is needed to trigger that, then make sure your u-boot recipe also selects that specific needed machine configuration Apr 09 07:28:24 fbre: if on the other hand you need some tool that is *NOT* included in u-boot, then you'll need to either find or write a recipe for it Apr 09 07:29:03 fbre: giving the layer index a quick skim for "mfg" suggests that you might want to start hunting here: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=mfg Apr 09 07:30:57 hmm, I have a yocto manual of NXP for their eval board, it also uses some freescale yocto layers, but I don't find config files for the generation of bootable images. That's why I'm asking. I'm not sure if it's an NXP-related problem or if there's a general approach already in the poky layer Apr 09 07:31:55 fbre: have you actually looked at the link? Apr 09 07:32:22 oh thanks, no, but thanks, I'll have a look now Apr 09 08:10:24 Reading all the recipes mentioned in http://layers.openembedded.org/layerindex/branch/master/recipes/?q=mfg is hell. What I need is a description of the concept behind. But there is nothing but tons of PDFs describing not what I want. *sigh* Apr 09 08:12:35 It's like being stucked in an adventure, but without having cheat codes to move on... :-/ Apr 09 08:13:43 fbre: well if it is hardware that you bought, then go to your supplier and demand proper support. if you're a hardware manufacturer yourself, well then this is part of your job Apr 09 08:20:51 The supplier support is their web forum, but all I usually get after hours of multiple question/answer iterations are links to PDFs describing details over details and refer to other PDFs with details over details, but no description of the relevant main concept. I bet it's actually said in less than 10 sentences. Absolutely frustrating. Apr 09 08:20:51 fbre: freescale has image recipes Apr 09 08:21:14 fbre: choose a better supplier :) Apr 09 08:22:12 The product gives the hardware price limit, and the price limit gives the supplier ;) Apr 09 08:22:58 fbre: and the price limits the support they can give you. its always the same dance. if you invest less in support to get, the more you have to do yourself Apr 09 08:25:18 we get our NXP based SOM $35 a pop and vendor support is fine Apr 09 08:25:31 it has to be much cheaper than that then Apr 09 08:27:43 a direct comparison of prices is not as easy as it often seems, if you take in account lead times, batch sizes, and guaranteed pricing for extended periods of time Apr 09 08:28:23 (generally) unless you're building the vendor-supplied image, then it's likely you'll need to put in some work in order to get any modifications to function the way you want Apr 09 08:28:47 I tend to view yocto/oe as an enabler rather than an out-of-the-box solution Apr 09 08:29:13 but generally my stance is: if you pick cheap hw with cheap support, then good luck. i don't see it as the responsibility of volunteers (like me, other paid supporters may differ, of course) to fix that support shortage Apr 09 08:29:19 I see, my build-wayland/tmp/deploy/images/imx8... directory is full of files like images, u-boot, *.bin and stuff, and I also see mfg and uuu tool is somehow working by their recipes, but no idea what it's all about and how their general yocto concept is for generating bootable images. What I need is a top-down approach of docs: "What images does booting expect? What is necessary to do to get there?" Apr 09 08:29:33 fbre: call mentor, wind river, etc and they'll happily do that stuff for you. Apr 09 08:31:24 fbre: you can of course always look at the recipe, find out who submitted them and ask tehre. Apr 09 08:32:05 yes, what I dislike is to purchase expansive support for things like explaining the overall concept in an understandable way which should actually be as a matter of course for every documentation Apr 09 08:32:10 which in the initrafs image example is otivio Apr 09 08:32:17 s/otivio/otavio/ Apr 09 08:32:23 otavio: ^^^^^^ Apr 09 08:32:50 fbre: well then go to nxp and your hw vendor and claim "this should actually be a matter of every documentation" Apr 09 08:33:24 fbre: otavio is usually around in us timezones, which means like 4 or 5hrs from now Apr 09 08:33:42 tz: perfect point of view. Apr 09 08:34:09 tz: its a tool you can get and either learn to use yourself, or pay someone to use and do the work for you. Apr 09 08:39:59 The whole mfg tool and uuu tool stuff is spread over many recipes. Is there a way to see in a final log how it has processed step by step during bitbake? Apr 09 08:41:08 fbre: of course. just build it, and then inspect tmp/work for the rpective arch/machine and recipes Apr 09 08:41:24 fbre: there will be logs for every task of every recipe Apr 09 09:00:12 hello there. i was wondering if anybody has a good idea on how to build an image file after building yocto for the raspberry pi. to speed up the build i created a remote VM, but i do not have a dedicated SD card slot for that one Apr 09 09:00:49 lastaid: i do not understand the question Apr 09 09:01:21 ok. i followed this guide: https://jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Yocto.html Apr 09 09:02:12 it worked great and now i have all the binaries build. i am wondering now, how can i create an image file instead of copying the files to a physical SD card manually. Apr 09 09:02:26 the build machine does not have access to an SD card reader or any peripherals Apr 09 09:02:47 i want an image i can flash with win32diskimager or dd Apr 09 09:06:12 lastaid: i personally have idea what the jumpteks are doing, but the "yocto-official" meta-raspberrypi layer provides exactly that: https://git.yoctoproject.org/cgit.cgi/meta-raspberrypi/about/ Apr 09 09:06:18 *have no idea. Apr 09 09:08:21 lastaid: i.e. use wic Apr 09 09:16:04 jofr: what is wic? LetoThe2nd: this is the first time i am using yocto. i am aware that i need to build my own recipe at some point, i will try the official recipe ! Apr 09 09:17:52 jofr: are you refering to the sdimage-raspberrypi.wks? Apr 09 09:19:09 lastaid: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-partitioned-images-using-wic Apr 09 09:32:50 ERROR: The following build artifacts are not specified: rootfs-dir, bootimg-dir, kernel-dir, native-sysroot Apr 09 09:33:27 wic seems like exactly what i want ... do the artifact names depend on the recipe? Apr 09 10:25:42 i have my image <3 switched from sysv to systemd, now my splash is gone :( Apr 09 11:27:13 What is the scope of MACHINE_FEATURES? Where can I amend or remove items from it? In the image recipe? In the distro? In local.conf? Apr 09 11:31:56 sveinse: technically "can" is in each .conf file Apr 09 11:41:46 only makes real sense in local.conf or your machine config Apr 09 11:50:48 There is a MACHINE_FEATURES_BACKFILL option qemu-usermode added by bitbake.conf. What does it do? The in-source doc is a little vague on what it does Apr 09 12:02:49 would you guys recommend systemd or sysv ? my main focus is fast startup Apr 09 12:07:15 We're using systemd and has decent boot times with it on an imx6(armv7) hw. It is a while since we changed from sysv, so I can't say comparative wise Apr 09 12:09:51 LetoThe2nd: You said at 10:41 every recipe has its logging in tmp/work. Where is the logging for imx-yocto-bsp/sources/meta-fsl/bsp-release/imx/meta-bsp/recipes-bsp/imx-mkimage/imx-boot_0.2.bb? Is there a certain pattern for finding the appropriate logging of a certain .bb file? Apr 09 12:40:30 sveinse: thanks. i do like systemd more, but now i am suffering from this issue described here https://lists.yoctoproject.org/pipermail/yocto/2018-May/041037.html Apr 09 12:42:35 lastaid: yeah, I've given up having a splash in the startup. Since it boots in <10 secs, this was acceptable by the product owner Apr 09 12:43:41 i'll check but i am getting around 15 seconds on my pi3. but yeah, having a around <=8 second boot time would be prefereable Apr 09 12:44:09 sveinse: last time i just wrote a quick logo to the framebuffer during boot Apr 09 12:45:18 lastaid: we had a splash in the bootloader too, but in our HW the kernel does a display teardown and reinit, so the splash lasted 0.5secs :( Apr 09 12:46:15 i'll try to lower boottime then ^^ Apr 09 12:51:58 lastaid: systemd can be a lot faster unless you've such a minimal system that a init service is useless and you can just straight into your app Apr 09 12:52:16 sveinse: says that qemu-user works reliably and can be used to run target code on the build host Apr 09 12:52:28 ie for gobject-introspection or font cache generation Apr 09 12:54:13 rburton: i literally just need qt and the standard pi display. and sdl for timers. but for fiddling around with yocto this is ok. do you have any experience with raspberry pi boot times on yocto? Apr 09 12:54:22 no Apr 09 12:55:07 Are you using boot2qt or meta-qt? Apr 09 12:55:46 i guess meta-qt? Apr 09 12:56:05 see i still have to find a tutorial how to set all those things up. Apr 09 12:56:25 also, didn't boot2qt have a different license of was statically compiled? Apr 09 12:56:30 *or Apr 09 12:56:37 if you have commercial license of qt you can use boot2qt Apr 09 13:43:38 Is VIRTUAL-RUNTIME_init_manager (and the likes) a image config or a distro config? I'm trying to decide where it most naturally should live Apr 09 13:57:23 hi Apr 09 13:57:54 I have this problem but i can't understand why... Apr 09 13:57:54 ERROR: Nothing RPROVIDES 'iperf' (but /home/fg/yocto/raspberry/poky/meta-rpi/images/qt5-basic-image.bb RDEPENDS on or otherwise requires it) Apr 09 14:23:40 hi! i'm trying to run a `-native` tool while building the image, which uses the `chroot` system call. i'm running it inside a `fakeroot` task (as described in the mega manual). though it seems that the `chroot` is not complete: `realpath` seems to return the wrong path Apr 09 14:24:20 is this a known issue or is there any other workaround (e.g. running the tool with real chroot capabilities)? Apr 09 14:51:12 is it ok to inherit useradd / add users in an image reicpe, or bad idea Apr 09 15:03:23 hm there's also 'extrausers'… Apr 09 15:03:47 timblechmann: ideally dont use a tool that needs chroot. seebs wrote pseudo which is implementing the fake-chroot though Apr 09 15:07:44 pseudo can fake enough of chroot for most of the install process, but realpath will not always be tricked. Apr 09 15:23:04 rburton, seebs: i'd like to run my tool to see the image as root filesystem (alternatively i'll have to prefix zillinons of APIs on my side) ... Apr 09 15:23:43 would there be other tools/techniques that i might miss? Apr 09 15:27:01 most things just know how to work in a subdir :) Apr 09 15:27:45 hmm. usually the chroot stuff provided is "good enough". I think the behavior of realpath is a compromise -- if we don't give real host-system paths, some other stuff breaks. Apr 09 15:28:07 what's the tool in question? Apr 09 15:28:35 I'm curious how realpath can sneak past the chroot jail Apr 09 15:28:51 because its pseudo's fake-chroot Apr 09 15:29:10 it's actually intentional-ish Apr 09 15:30:14 hmm. i'm not actually sure what would break if we just changed realpath. it needs to do its path resolution inside the chroot directory, but it might be sane for it to then return the path relative to that directory. Apr 09 15:30:17 aha, chroot is a privileged op, so in order for pseudo to work unprivileged it cant use real chroot Apr 09 15:30:35 and we don't actually entirely want it to! Apr 09 15:30:48 for instance, if you exec /bin/sh, we want to execute the host /bin/sh, because it will actually run Apr 09 15:31:08 I see Apr 09 15:31:11 it turns out the entire idea of pseudo is completely insane Apr 09 15:31:18 and no one should ever have tried to do such a thing Apr 09 15:31:53 it did lead to a really funny conversation, though Apr 09 15:32:29 i commented on the relatively small number of string-manipulation bugs in pseudo (one i can remember, a special-case off-by-one error in the path resolution code), and someone started lecturing me on how i shouldn't have done this in C, I should have done it in Python. Apr 09 15:32:56 not sure how one writes a preload library in python Apr 09 15:33:01 rust, however ;) Apr 09 15:33:48 did rust *exist* in 2008 or so? Apr 09 15:34:11 in the medium-to-long term, i suspect pseudo's doomed -- too many things that don't always go through libc. Apr 09 15:34:13 RP: ++ on mal Apr 09 15:34:17 mail, even. Apr 09 15:35:23 I can do one worse: We had a similar system in our pre-OE build system. It created a sysroot for building using the target machine, so the "pseudo" tool depended on both chroot and on binfmt to execute armhf binaries on intel... Apr 09 15:38:15 seebs: I think pseudo has done quite well all things considered :) Apr 09 15:38:50 Well, that a bit unfair, it does work, but requires elevated privileges and is slow since some executables can be armhf binaries. It was the only way back in 2011 that I was able to compile the loads of software that blindly assume that you can run the executable which you are compiling Apr 09 15:40:29 It is essentially containers, which has become immensely popular a few years later Apr 09 15:40:46 i am really pleased with how long it's stayed viable. Apr 09 15:40:57 i am still very positively impressed with WR management at the time Apr 09 15:41:17 we were already arguably late on our schedule, but i went to them with my argument for "no, really, we *have* to replace fakeroot", and they let me try it. Apr 09 15:41:37 i think the highlight was a patch that made something like six different changes to try to make fakeroot more reliable, and appeared to help some in testing Apr 09 15:42:00 and then we noticed something weird, and it turns out, four lines *above* the patch, in the makefile, there was a missing \, so *none of the changes had any effect at all*. Apr 09 15:42:15 and the fact that we *could not tell this* was what finally convinced me that we had Insufficient Confidence In This Code. Apr 09 15:42:17 When I started with OE, I rember being impressed by pseudo. I was thinking something like "oh, that's smart. I've should've thought of that for our project." The db handling which enables multiple sessions Apr 09 15:42:44 it was very much built in terms of "what is everything that has ever frustrated me even once in fakeroot" Apr 09 15:43:09 i don't wanna imply that the fakeroot people are bad, btw. it's an insanely hard problem, and you have to try things to find out what works. Apr 09 15:44:57 Yeah, one "side effect" is that you have to go via. tarballs rather than sharing unpacked dirs to be able to retain proper permissions unless the database of permissions can be kept Apr 09 15:47:28 yeah. the databases are inherently not very portable. part of that is the overhead of extra tracking which exists to identify where errors are coming from. Apr 09 16:41:29 Can bb.utils.contains be used to check for whole contents? E.g. will it work to use this in a RDEPENDS list? ${@bb.utils.contains('PREFERRED_PROVIDER_virtual/kernel', 'linux-dummy', '', 'kernel-dev' ,d)} Apr 09 16:43:47 Throwing this out here... With the immediate cessation of Eclipse support for YP, wondering if I should start the removal process of Eclipse from the documentation. Or, if a "waiting" period is in order in case a "saving catch" is made and someone steps up to support the plug-in. Opinions are appreciated. Thanks. Apr 09 16:51:26 scottrif: ooi, a recent decision? Apr 09 16:52:27 sveinse: I just learned of it today Apr 09 16:53:05 scottrif: it sounds like a sudden event/decision Apr 09 16:53:49 sveinse: sudden decision as we realised we have nobody to support releasing the plugin any further and builds keep breaking Apr 09 16:54:00 sveinse: I don't know the specifics behind it other than impact it would have on the user docs. Apr 09 16:54:04 sveinse: we have asked for help multiple times Apr 09 16:55:11 RP: ah right, thanks. I feared that is was decided to be removed for some non-technical reason, e.g. politics Apr 09 16:55:38 sveinse: purely down to nobody to look after it Apr 09 16:56:20 RP: I understand. (I'm not using it myself. I'm using VS Code mostly.) Apr 09 16:59:09 It is really convenient to make a custom distro. But man, it's boring to wait when you get a complete rebuild due to a small change in it :( Apr 09 16:59:32 sveinse: there are ideas for allowing workarounds for that Apr 09 18:05:58 Quick question: What is the correct way to pass a library to oe_runmake? ld is complaining that it can't find a library specified by DEPENDS in the recipe. Like what directory should I include (-L) for LDFLAGS for things installed by the recipe Apr 09 18:07:26 jrypkec: you don't need to set anything if the other recipe installed to the right place, as long as your buildysstem is obeying our CC/LD vars Apr 09 18:07:30 as we pass —sysroot= Apr 09 18:10:55 Ok thank you Apr 09 18:11:48 so i'd 1) make sure the other recipe put the right files in the right place, and 2) make sure our CC/LD are being passed into the underlying buildsysstem. check the compile log Apr 09 18:14:15 I keep getting a taskhash mismatch error. Even when I'm running bitbake -c clean on the very recipe that complains about taskhash mismatch. I'd hope the clean could be sufficient Apr 09 18:18:44 I fixed it by erasing build/tmp and start over. This is the most effective way to fix taskhash mismatches. I just <3 the sstate cache mechanism. Beautiful! Apr 09 18:19:11 hash mismatches usually result from the metadata changing out from u nder bitbake, which usually is caused by timestamps or reading from external files that mght or might not exist. though that's more often basehash than taskhash, admittedly Apr 09 18:20:04 yeah, I've had more than one attempt at hunting them down, but they are very elusive or cryptic unfortunately Apr 09 18:20:38 there's a bitbake patch floating around that's useful for that, it dumps the intermediate basehashes, not just the final, so you can compare Apr 09 18:26:47 RP, you still sitting on my two GO patches? I am going to have to buy some plane tickets. Apr 09 18:31:35 maybe a beering will help :D Apr 09 18:36:48 marka: ah, yes. Need to look at and sort that Apr 09 18:37:04 thanks Apr 09 18:37:18 we can arrange the beering for another time Apr 09 18:39:17 marka: I'm open to beering as a method of persuasion :) Apr 09 18:39:45 hopefully we will end up at the same conference at some point Apr 09 18:42:47 if it helps any I have been building for x86-64, arm and aarch64 with those two GO changes for 2 weeks now, including most of the GO recipes in meta-virtualization Apr 09 18:43:58 I have some other changes I need to get to zeddii to allow him to do so as well, but only after those are merged to master Apr 09 18:48:08 * zeddii accepts beer as well. Apr 09 18:48:44 marka: perhaps you could sort my python3 ptest problems and I'll review your patch? :) Apr 09 18:53:38 woah, let's not get too friendly Apr 09 18:54:02 * marka has done hand to hand with pythong 3 from time to time as well Apr 09 18:54:28 and yes, it is pythong, that is how it always comes out when I type it Apr 09 19:06:33 marka: I keep needing to type unbuffer in relation to ptest but the f and g keys are close... Apr 09 19:06:55 :) Apr 09 19:07:10 something else seems more appropriate Apr 09 19:07:18 I lived in Aus for just under 2 years, so I understand the bugger Apr 09 20:11:07 I thought local.conf had the highest authority on vars, but apparently not. I'm trying to unset a variable, but the overrides kills my efforts https://bpaste.net/show/eb02ac78c47f Any ideas guys? Apr 09 20:13:52 machine .conf and distro .conf are parsed afte rlocal.conf, as DISTRO and MACHINE are generally set there, so it's not viable to do otherwise Apr 09 20:14:04 either the machine .conf or distro .conf need to use ?= or ??=, or you'll have to use an override, i..e forcevariable Apr 09 20:14:42 kergoth: how do I do the latter? Apr 09 20:14:50 FOO_forcevariable = "1" Apr 09 20:15:06 same as with any otehr override Apr 09 20:15:17 see the yocto project docs or bitbake user manual for how overrides work Apr 09 20:16:44 Thanks. I've read the docs about this a few times, but I have a really hard time grasping it. I must be slow Apr 09 20:18:45 it's just a way to allow more specific information to be used in preference to less specific information. info about a board is better than info about its architecture which is better than the global defaults Apr 09 20:19:00 conceptually it's almost a layering mechanism, though not our layers Apr 09 20:19:30 it's reflected both in OVERRIDES (see bitbake.conf) and the order the files are included in bitbake.conf (where viable, also see bitbake.conf) Apr 09 20:20:40 Problem is that it is combined with scoping and operator declarations too e.g. PACKAGECONFIG_append_pn-qtbase Apr 09 20:25:18 it's just a conditional Apr 09 20:25:24 append/prepend/remove if this condition is true Apr 09 20:25:26 As for the above problem: it worked putting PACKAGECONFIG_GL_pn-qtbase_forcevariable = "", but I don't understand why PACKAGECONFIG_GL_pn-qtbase = "" won't. And what is "forcevariable"? I understand it an arbitrary override name, but it isn't declared or set anywhere so why did it take effect? Apr 09 20:25:28 no more complex than an if statement Apr 09 20:25:57 most likely a machine or distro config was setting PACKAGECONFIG_GL_pn-qtbase already, after you set yours Apr 09 20:26:08 forcevariable *is* declared somewhere, in OVERRIDES, as i said earlier Apr 09 20:26:27 its purpose is exactly this, to let the user override something from local.conf regardless of any other overrides in play, as it's the highest priority one Apr 09 20:26:47 oh, is is, yeah. lots of it in the sources Apr 09 20:27:30 it's purely brute force, ideally we woudln't have to use it, but it's useful for working around casese where someone forgot to use ?= in machine .conf or distro .conf Apr 09 20:27:32 I can't origin from the machine nor the distro, as I'm controlling both Apr 09 20:27:41 use bitbake -e. Apr 09 20:27:43 it can't Apr 09 20:27:49 not only does it show you the value, but it shows you the history of varaible changes Apr 09 20:27:53 what lines in what files set it the way it is Apr 09 20:27:55 Did you see the my paste above? Apr 09 20:27:59 so drop the _forcevariable, use bitbake -e and Apr 09 20:28:00 There is the history of it Apr 09 20:28:02 see where the value is coming from Apr 09 20:28:34 yep, i see it now. what you're missing is that overrides have a priority Apr 09 20:28:39 this is how we implement specificity Apr 09 20:28:44 right Apr 09 20:28:50 both arm and ${MACHINE} are in overrides, but if both are set, the latter wins Apr 09 20:29:00 it's the order of items in OVERRIDES, much like the order in PATH Apr 09 20:29:14 got it Apr 09 20:29:47 it's complex, but we had to have a way to allow this sort of layering of information across all the metadata everywhere, regardless of where it was coming from Apr 09 20:29:56 (thinkingn back to the original design discussions) Apr 09 20:30:37 the alternative would have been to implement actual conditionals in the file format, but taht's more imperative, and order of operations becomes much more critical in that sort of setup Apr 09 20:30:41 It's an odd assumption made by the machine layer vendor: Assuming that you the machine has opengl support you definitely want to compile qt5 with opengl. But I don't... Apr 09 20:30:46 (i.e. if this; foo=bar; endif) Apr 09 20:30:54 that is weird indeed Apr 09 20:31:19 In the bpaste, there is a bunch of qtbase_%.bbappends Apr 09 20:33:45 as to the design discussion yes: I see the purpose of it. And it is powerful. But implicit syntax, rather than declarative, is very difficult to trace. Just look at m4 or tex. However, the bitbake -e function is a lifesaver in terms of determining the lifecycle of the var Apr 09 20:34:45 That said, I didn't understand from the -e output why my var was overwridden by an override. I had to seek advice for it. Apr 09 20:38:48 Hello there... I was just reading about RCONFLICTS in the yocto reference (https://www.yoctoproject.org/docs/2.6.1/ref-manual/ref-manual.html#var-RCONFLICTS) and the example even though it's probably wrong confirms my suspicion, that RCONFLICTS has also the effect of RDEPENDS. Is this really the case? Apr 09 20:40:53 RCONFLICTS_${PN} = foo (< 1.0) is equal to RDEPENDS_${PN} = foo(>=1.0) ? Apr 09 20:41:05 maybe not equal but similar Apr 09 20:49:10 sveinse: hmm, yes, it shows the override values being set, but not why it chose one over another. arguably that's a bug in bitbake -e, it should show something about the overrides priority. could open a bug? Apr 09 20:51:41 I'm on older rocko thou, perhaps this has been fixed to newer versions Apr 09 21:09:17 zeddii: wish you used error on dangling bbappend :) Apr 09 21:09:29 zeddii: (meta-yocto-bsp still had a 4.18 append) Apr 09 21:10:33 alimon: around? Apr 09 21:22:01 marka: still there? Apr 09 22:46:01 New news from stackoverflow: imx6ul - how to select the right dts for sdcard image? Apr 09 23:09:57 RP: ahahah. yah, I have some layers that have danglers by design, so I always have it inhibited :( Apr 09 23:10:32 zeddii: We need a better API for that Apr 09 23:10:53 I assume you've squashed it now, and don't need a patch from me. Apr 09 23:11:13 zeddii: yes, I just removed it Apr 09 23:11:19 indeed. I wish I could whitelist for some of my things, but fail on others, etc. Apr 09 23:11:32 zeddii: I bet we could enhance bitbake to do that Apr 09 23:12:13 bitbake becomes self aware Apr 09 23:13:39 then it sends back a T800 to 1984? Apr 09 23:14:00 * zeddii scratches out a note to look into something like that Apr 09 23:14:17 zeddii: we should put an ehancement in the bz Apr 09 23:14:31 I have good and bad news re: pseudo :/ Apr 09 23:14:31 I can do that. Apr 09 23:14:56 the good news is we understand why it breaks. The bad news is we need to fix this before release as new versions of coreutils will cause problems Apr 09 23:15:12 sounds like it was fun to debug. Apr 09 23:15:25 * RP really appreciates seebs' help Apr 09 23:15:36 and otavio's help too Apr 09 23:19:59 i should totally figure out how to get someone to throw me money for working on this sometimes. :) Apr 09 23:20:39 seebs: yes, I wish I could figure that one out... Apr 09 23:20:39 rumour is it that people get paid for software work. unless your name rimes with beebs Apr 09 23:20:43 heh Apr 09 23:21:00 well i mean, i do get paid for software work, just not this specific software work, since there's no clearly defined entity that has a business case for funding it Apr 09 23:22:06 seebs: its hard, I know the "fun" I've had trying to stay on the project Apr 09 23:22:32 $dayjob will probably let me get away with it, they're pretty cool Apr 09 23:25:20 seebs: that is cool :) Apr 09 23:25:44 (and much appreciated as I'd never have found the other path bug) Apr 09 23:26:09 seebs: I've pointed someone else at pseudo master who was having pseudo errors Apr 09 23:26:19 * RP -> Zzzz **** ENDING LOGGING AT Wed Apr 10 02:59:57 2019