**** BEGIN LOGGING AT Mon Jan 27 02:59:58 2020 Jan 27 07:45:29 hello everybody Jan 27 07:45:52 I face this error - This application failed to start because it could not find or load the Qt platform plugin "xcb" while trying to run my UI Jan 27 07:45:54 any help ? Jan 27 07:47:32 moustafa: did it already work? so is this a new problem, or the getting started stage? Jan 27 07:49:10 moustafa: and, di you properly build and package your application, or are you using some copy-things-here-and-there workflow? Jan 27 08:13:35 moustafa: Qt can be built and used with a lot of different platform plugins, depending on if you use e.g. Xorg, Wayland or just want to draw using eglfs or linuxfb. If you run the app with "-platform foo" as argument it will display a list of the available platform plugins. Jan 27 08:14:31 moustafa: what machine and image are you using? Jan 27 08:20:49 New news from stackoverflow: how to include python pex package in yocto image Jan 27 08:33:46 erbo I am using minnowboard turbot with wayland protocol Jan 27 08:36:09 moustafa: so you're running a wayland compositor too, like e.g. weston? Jan 27 08:38:17 erbo yes Jan 27 08:38:31 moustafa: check if your Qt build includes any wayland backend by checking the list of plugins as I suggested earlier, and try to use that by specifiying -platform Jan 27 08:40:00 my guess actually is that the board runs yocto, but the application comes from "somewhere" Jan 27 08:40:32 LetoThe2nd: I'm not so sure, when you built qtbase you specify the default platform plugin which is xcb by default Jan 27 08:40:58 erbo: just guessing :) Jan 27 08:41:20 So unless you know that you should set that up properly, you will most likely need to specify the correct platform plugin when launching it Jan 27 08:41:53 when I am using -platform eglfs or wayland it gives me the same error Jan 27 08:43:02 that it couldn't find or load wayland plugin? Jan 27 08:43:13 or still the xcb ? Jan 27 08:43:25 still the xcb error Jan 27 08:44:11 but did you get the list when you used -platform foo? Jan 27 08:44:17 no Jan 27 08:44:17 That sounds weird Jan 27 08:45:14 So your app, is it possible it overrides Qt default argument parsing that accepts the -platform parameter? Jan 27 08:45:20 What app is it= Jan 27 08:45:43 My god, I really can't produce correct english this morning Jan 27 08:47:52 I found some list of Available platform plugins are: minimal, offscreen ... Jan 27 08:49:04 Is those all you have? Jan 27 08:49:36 Available platform plugins are: minimal, offscreen, vnc, wayland-egl , wayland Jan 27 08:49:39 that's all Jan 27 08:50:20 Then you need to look into how your Qt build is set up. If you use meta-qt5 you need to look at https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtbase_git.bb to see which PACKAGECONFIG options you need to enable on your platform. Jan 27 08:51:16 Oh wait, the wayland one is actually it's own recipe. https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtwayland_git.bb Jan 27 08:52:18 Sorry, didn't see you provided an updated list. So you do have wayland there Jan 27 08:52:26 Yes Jan 27 08:52:33 and wayland-egl Jan 27 08:53:09 But -platform wayland produced an error about not being able to load xcb? Jan 27 08:53:20 yes exactly Jan 27 08:53:38 Try setting QT_QPA_PLATFORM=wayland Jan 27 08:53:50 it's another way of specifying platform plugin Jan 27 08:55:16 ok where Jan 27 08:55:32 ok where i cann add this setting ? Jan 27 08:56:23 It's an environment variable, if you launch if via a shell you can just put that text at the beginning on the line you use to start it Jan 27 08:56:32 How do you start the app? Jan 27 08:57:25 export QT_QPA_PLATFORM=wayland im assuming Jan 27 08:57:31 from terminal Jan 27 08:59:26 yeah then you can export it before, or just do QT_QPA_PLATFORM=wayland ./my-awesome-app Jan 27 09:03:24 Yup Jan 27 09:03:27 ok thank you so much Jan 27 09:03:28 That will work Jan 27 09:03:36 it's working Jan 27 09:05:17 Nice. So if you want it to be default you can create a qtbase_%.bbappend containing: QT_CONFIG_FLAGS += " -qpa wayland " Jan 27 09:05:39 But usually it's not that annoying to specify it when running the app Jan 27 09:06:26 aha ok Jan 27 09:06:30 thanks allot Jan 27 09:20:22 good morning Jan 27 10:15:26 I don't understand the autobuilder failure :( Jan 27 10:16:01 RP: s/failure//g Jan 27 10:44:02 Everytime I type "bitbake ", the recipe rebuilds from scratch. How do I debug why bitbake thinks it needs to rebuild everytime ? Jan 27 10:45:31 kroon: bitbake-diffsigs -t bitbake build Jan 27 10:49:00 qschulz: just out of curiosity. how exactly does that command work? it seems to nee some 'sigfiles'. where do i get them? Jan 27 10:53:15 creich: tmp/stamps Jan 27 10:53:28 bitbake-dumpsig to read the stamps Jan 27 10:54:45 thx :) Jan 27 10:57:57 sorry to bother again on that, but i keep getting 'ERROR: No sigdata files found matching busybox do_build' Jan 27 11:00:14 tried several other packages that are for sure listet in the tmp/stamps folder Jan 27 11:01:05 creich: you most likely used the sstate-cache and removed the tmp dir in-between builds Jan 27 11:01:17 qschulz, thanks Jan 27 11:01:31 creich: in which case, they're not there anymore :) Jan 27 11:01:48 kroon: pleasure, I very much like this command :) Jan 27 11:02:06 is that cache activated by default? Jan 27 11:02:51 i am going to check if it's on. thank you :) Jan 27 11:11:33 how can I easily track down what in my image depends on python2.7? Jan 27 11:12:03 does opkg have equivalent of dpkg-reconfigure? Jan 27 11:14:38 stuom1: PNBLACKLIST[python] = "no more python for you" and rebuild, see what breaks Jan 27 11:21:15 @rburton thanks, I will try that Jan 27 11:37:02 python2.7 seems to be required by "perf" that is apparently required by my image.bb, but at least directly it is not. How do I now know what in my image needs perf... Jan 27 11:38:03 am i right when saying that signatures have to be activated manually? like 'bitbake -S XYZ'? Jan 27 11:38:07 i just don't see how or when i should have (accidentially) activated sstate-cache. anything i can read to understand that thing better? or any idea what i might do wrong here? Jan 27 11:41:20 nevermind my last message, im blind... Jan 27 11:58:21 creich: sstate-cache is always enabled AFAIK Jan 27 11:58:38 that's the thing that makes rebuild way faster Jan 27 11:59:45 ah, ok.. so i got your message wrong i guess. you just wanted to point out, that i might have deleted tmp at some point in time, while still having the state active... Jan 27 11:59:59 proably. i just deleted everything and started with a fresh build Jan 27 12:00:22 just noticed, that there have been no sigfiles at all in the stamps folder and i am not sure why Jan 27 12:04:10 creich: like not a single one for any packagre? Jan 27 12:05:09 creich: find -name "*sigdata*" in tmp or ANY directory that is used by Yocto and try to find where those files are. Jan 27 12:26:50 would say they havn't been there, but not sure anymore, since i deleted the workspace Jan 27 12:27:04 now in my clean build, they are where they're supposed to bw ;) Jan 27 12:27:15 thank you for your help and patience :) Jan 27 12:27:45 creich: np, I also wondered why the files weren't there anymore a few days ago :) been there done that Jan 27 13:48:43 I'm trying to understand ptest by looking at oe-core recipes where it is enabled, and they all include file://run-ptest but I cannot find this file in any of the sources? Jan 27 13:48:59 where is it coming from? Jan 27 13:51:07 stuom1: They're written by whomever adds the ptest. Usually they are some cut-down call to the source's "make check" or "make tests" but with some customization to make it work on our target Jan 27 13:53:24 why is the file not shipped in the sources of any of those packages Jan 27 13:55:37 its in the SRC_URI for the recipe Jan 27 13:55:51 its oe-specific so won't be upstream Jan 27 13:56:18 the actual file is alongside the recipe in the layer Jan 27 13:56:46 eg https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/glib-2.0/glib-2.0/run-ptest Jan 27 13:57:17 even simplier https://git.openembedded.org/openembedded-core/tree/meta/recipes-graphics/pango/pango/run-ptest Jan 27 13:59:25 For comparison, a more complex one http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/valgrind/valgrind/run-ptest Jan 27 13:59:46 Aaa, ok, so it is just not listed in the layer index page like patches and other files? for example pango http://layers.openembedded.org/layerindex/recipe/488/ Jan 27 14:00:12 I looked in layer index and that file is nowhere listed in any package Jan 27 14:00:33 like patches and other stuff in SRC_URI Jan 27 14:01:00 arguably it should be in the Sources list, not sure why it isn't Jan 27 14:01:16 file a bug for the layer index? Jan 27 14:01:18 Ok, thanks, now it is more clear :P Jan 27 14:01:44 I can file Jan 27 14:21:23 order of layers in bblayers does matter? I think it is, but what is the rule to make the layer order, I've a layer that behaves different when order changes Jan 27 14:21:44 bat thing is, it doesn't work in either way Jan 27 14:21:57 xtron: it doesn't matter if you're doing only nice things :) Jan 27 14:23:11 LetoThe2nd, ok when I add meta-security in my build thing went wrong, and I can't find what wrong with the meta-security, it's an upstream layer Jan 27 14:24:02 xtron: "think went wrong" Jan 27 14:24:11 i've never seen that bitbake message, sorry. Jan 27 14:24:52 it could find tasks available in *.bbappend Jan 27 14:25:44 couldn't* Jan 27 14:26:13 that rather sounds like mixed revisions or missing layer dependencies. Jan 27 14:29:42 LetoThe2nd, some thing like when trying to use zeus compatible layer with sumo? Jan 27 14:32:07 xtron: that scrams for troubles, totally irrespective of bblayer order. Jan 27 15:30:33 how does one list the kernel's CONFIG_* variables after building ? The closest I've got so far is using "bitbake -e linux-raspberrypi". Jan 27 15:31:13 meego: look at the kernel build directory, the resulting .confg file should be there. Jan 27 15:31:36 @LetoThe2nd thanks Jan 27 15:32:22 if the kernel has embedded .config enabled, a copy will be in your running device. Jan 27 15:32:31 If not, you'll have to dig it out of the build directory Jan 27 15:33:19 yeah once you got a system up and running thats the alternative. Jan 27 15:33:39 fray: yeah i tried that but it seems proc/config is disabled. Thanks Jan 27 15:34:45 maybe you need to modprobe configs first Jan 27 15:35:06 or even install the kernel-modules-configs first Jan 27 15:51:31 i see lots of kernel-related .config files in tmp/work & tmp/work-shared but they all seem to either be machine-specific or arch-specific. Where should the merged version be ? Jan 27 15:56:46 meego: well... the kernel is machine specific? what's exactly your issue? Jan 27 16:01:33 qschulz: ah ofc. This looks like the one, isn't it ? (I'm building for RPi3) tmp/work/raspberrypi3-poky-linux-gnueabi/linux-raspberrypi/1_4.19.71+gitAUTOINC+13ce09db83-r0/linux-raspberrypi3-standard-build/.config Jan 27 16:02:00 meego: what is your isse? why do you want to know about .config? Jan 27 16:06:30 qschulz: i am missing some devices (empty /proc/asound/cards & /dev/rtcN) after switching my image's parent class from core-image to core-image-minimal. I want to make sure the kernel still has the necessary configuration to make both work. Plus now i also want to enable /proc/config.gz (modprobe didn't help) Jan 27 16:08:37 meego: you can check whatever is enabled with a gui-like interface with bitbake -c menuconfig virtual/kernel but honestly it sounds weird. Maybe you're missing the kernel-modules, try to add that in your IMAGE_INSTALL or CORE_EXTRA_IMAGE_INSTALL Jan 27 16:09:01 meego: and it seems weird because the image shouldn't be able to impact the packages at build time. only machine, distro or local.conf can Jan 27 16:10:18 so I guess you're just missing the kernel-modules. You can fine tune them and have only the ones you want to include either by modifying the defconfig of the kernel or include kernel-module-xyz instead of kernel-modules Jan 27 16:10:26 let us know if that fixes it? Jan 27 16:11:09 qschulz: that's useful pointers, thanks Jan 27 16:11:46 RP, you know if using hashequiv and sstate-cache-management.sh script plays along nice together ? Jan 27 16:13:49 kroon: does the script work since the sstate-cache has another directory level? Jan 27 16:14:16 JaMa, I haven't seen any error messages at least :-) Jan 27 16:14:41 (yes i'm on master branches everywhere) Jan 27 16:15:08 I'm a little confused concerning how hashequiv has changed things Jan 27 16:16:19 kroon: I don't... Jan 27 16:16:44 kroon: I'd have thought the common codepaths would still touch sstate access stamps so it should still work Jan 27 16:19:02 RP, I was in a state where doing "bitbake openjre-8" always rebuilt, and bitbake-diffsigs didn't help. So I thought maybe hashequiv+sstate-cache-management.sh confused things. So now I've wiped cache/ to remove the hashequiv db and rebuilding Jan 27 16:20:08 And even though it rebuilt, I never saw any sstate cache being created Jan 27 16:20:12 kroon: I'd have thought it easier to debug when it was reproducing. I don't have any insight to offer offhand though :/ Jan 27 16:20:26 * RP needs to focus on getting green autobuilder builds again Jan 27 16:21:13 RP: green? autobuilding for future? Jan 27 16:25:53 LetoThe2nd: things are currently consistently failing :( Jan 27 16:33:25 RP, no worries, just wanted to check if you had any thoughts on the matter Jan 27 16:38:28 JPEW: Found a problem in kbd which I'm hoping may resolve some of the repro build issues Jan 27 17:00:33 JPEW: looking at a nice looking sledgehammer for the SHELL issue Jan 27 17:10:16 RP, the buildtools work for older and newer gcc's. Are we good for backporting yet? Jan 27 17:14:38 qschulz: re-adding the kernel-modules did the job. Thanks again ! Jan 27 17:15:08 armpit: you tested them? Jan 27 17:23:25 maybe I am getting confused. are the binutils sdk changes needed? Jan 27 17:25:09 armpit: ultimately, yes. But we do really need to have some test branches and test them in the older releases first Jan 27 17:25:22 armpit: we're missing the autobuilder pieces to do this right now Jan 27 17:27:31 I am trying to build an image with development tools installed (gcc, gdb, g++, pkg-config..etc) but these tools are not being installed into my resultant image when supplying the following EXTRA_IMAGE_FEATURES += "tools-sdk tools-debug tools-profile tools-testapps package-management". Jan 27 17:28:18 I am working with the APQ8053 and using the CAF supplied yocto-based bsp. Anyone have any ideas? Jan 27 17:28:59 RP, ok.. Ill see what I can do Jan 27 17:29:30 armpit: if it helps I have the test branches I mentioned Jan 27 17:32:16 rob_gries: Maybe you can try to output environment of your build. bitbake -e your_image | less, and search for EXTRA_IMAGE_FEATURES to see if it's being set correctly? Jan 27 17:33:19 I would probably check IMAGE_FEATURES, instead. Jan 27 17:36:28 Interesting dilemma. Should we force CONFIG_SHELL to be /bin/sh or /bin/bash for configure? Forcing to /bin/sh isn't deterministic since it detects if its bash or not and changes its quoting mechanism :/ Jan 27 17:55:44 JPEW: build running with the above tweak, hoping it helps with the repro failures Jan 27 18:06:58 RP: I've got a series for v5.4 that I can send out to the list, I was thinking of doing one more AB run, is there a better (or worse) time for that ? Jan 27 18:17:20 RP: bash is entrenched in autotools I have seen it elsewhere Jan 27 18:17:37 perhaps better to use bash always maybe :( Jan 27 18:18:40 rob_gries: usually this means someone is overwriting EXTRA_IMAGE_FEATURES you need to trace that perhaps bitbake -e is a good option to debug that Jan 27 18:19:00 thanks, I'm looking that over now Jan 27 18:19:23 RP: force to bash Jan 27 18:19:45 usually best is to use _append EXTRA_IMAGE_FEATURES_append = " ...." Jan 27 18:30:21 JPEW: i assume you're using the uSD card on the rock pi 4? Jan 27 18:42:27 armpit: looking at meta-security's master-next, I see you fixed linux-yocto-dev.bbappend, but linux-%_5.%.bbappend is still present. That's effectively linux-%.bbappend, breaks e.g. linux-raspberrypi compile in AGL which has smack enabled... Jan 27 19:02:48 tlwoerner: Yes. I think the eMMC could be easily supported with another wks file Jan 27 19:04:30 RP: Ya, I don't know which is better between /bin/sh and /bin/bash Jan 27 19:04:51 RP: I logged some of the repro problems in bugzilla... there are more though Jan 27 19:04:53 JPEW: how are you powering the board? when i plug it in i get nothing, no LEDs, nothing Jan 27 19:05:07 USB-C charger from my phone? Jan 27 19:05:22 Do you have a serial console attached to the header? Jan 27 19:05:46 JPEW: serial? yes Jan 27 19:06:11 tlwoerner: The cheap one that used prevented it from booting in that way Jan 27 19:06:24 my ASUS chromebook USB-C adapter doesn't specify that it's "USB PD" or "qualcomm qc" so maybe that's my issue Jan 27 19:07:32 tlwoerner: Maybe. Mine is from my Pixel 2... I haven't tried a more generic one. Jan 27 19:07:50 ahh... unplugging the console cable the green LED now lights up Jan 27 19:08:41 tlwoerner: You can plug it back in after the light comes on Jan 27 19:09:11 tlwoerner: I got one of these and it works better: https://www.amazon.com/gp/product/B07RBKCW3S/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 Jan 27 19:10:01 tlwoerner: But beware: The green and white pins are backward Jan 27 19:10:42 that's a new one, i've never seen a serial cable interfere with booting Jan 27 19:11:00 sweet, it works (by plugging in the cable after booting) Jan 27 19:11:17 tlwoerner: I've had to put 100 Ohm resistors on almost all of mine because they were backpowering the boards Jan 27 19:11:45 tlwoerner: The only one that didn't have that problem was my raspberry Pi Jan 27 19:12:23 tlwoerner: Well, and the RockPi4... I suspect it was somehow holding the CPU reset pin Jan 27 19:21:52 JPEW: when you say that one "works better" you mean it actually works? i.e. with no tricks? Jan 27 19:23:13 tlwoerner: Right, you can leave it plugged in all the time. It also can reach the 1.5 Mbaud speed that the RockPi4 uses (which my others couldn't) Jan 27 19:23:45 tlwoerner: I may have chosen poorly on my first batch, give how much trouble they've been :) Jan 27 19:23:51 okay, i'll grab one of those. i can't seem to find my adafruit console cable to see if that one will work Jan 27 19:24:28 tlwoerner: still no word from that prof? Jan 27 19:24:58 tgamblin: sadly no. i'll poke him again, thanks for the reminder Jan 27 19:25:05 No worries Jan 27 19:26:22 JPEW: i've got a bunch of those "raspberry pi" ones from digikey/mouser, the speed seems fine, but they can't be plugged in at boot Jan 27 19:27:12 JPEW: do you have a pic of the 100 Ohm tweak? are they just in series with the TX/RX lines? Jan 27 19:27:22 Just the TX line Jan 27 19:27:47 err, USB TX -> Pi RX Jan 27 19:28:02 so the pin furthest from the ground? Jan 27 19:28:25 Yes, I think so. Don't have the boards ATM Jan 27 19:29:07 tlwoerner: The idle signal level for serial is high, so the target device can end up accidenly drawing power from it. Jan 27 19:29:30 The resistor makes it not able to draw enough to actually power anything :) Jan 27 19:29:56 i've noticed on other boards that often the serial cable will cause the onboard LEDs to glow ever so faintly, but i've never seen a case where the console cable prevented the board from booting :-) Jan 27 19:30:18 tlwoerner: Ya, I was paranoid so I added the resistors if the LEDs were lighting Jan 27 19:30:59 I've seen the serial prevent the CPU from resetting properly on power down... latches something high and the CPU doesn't reset properly Jan 27 19:50:07 JPEW: in any case, it's pretty sweet to see the built images booting :-D Jan 27 19:51:40 ...and it's nice to see the bmap stuff working Jan 27 19:54:40 I've got a kernel patch included through a recipes-kernel/*.bbappend. I also have a user.cfg that I use to implement CONFIG_ options when building the kernel. However, I don't appear to be able to set a CONFIG options that is defined by my patch. Jan 27 19:59:17 JPEW: out of curiosity, what is the deploy class doing? Jan 27 19:59:44 that is, my patch defines a whole new driver, and patches the makefile and kconfig files with CONFIG-dependent behavior. But of course, when I run bitbake -c menuconfig virtual/kernel, I can't find my driver in the menu system because the patch hasn't been applied. Jan 27 20:01:05 tlwoerner: sets up do_deploy to do sstate properly: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/deploy.bbclass Jan 27 20:11:31 JPEW: interesting! i thought all recipes had a deploy task by default. so a do_deploy is needed when manually stuffing things into the deploy folder? e.g. pre-compiled binaries? Jan 27 20:38:20 RP: http://ix.io/28wv it seem bash change related ? Jan 27 21:13:22 khem: possibly, yes Jan 27 21:14:11 khem: almost certainly. I ran it through the autobuilder to see how bad the issue was Jan 27 21:14:23 khem: the puzzle is how this issue didn't appear before now Jan 27 21:14:48 looks like a problem with grep and xz Jan 27 21:17:23 RP: if I build it natively on my box then I dont see /bin/bash creeping in Jan 27 21:17:27 on xz Jan 27 21:18:50 khem: your /bin/sh is ??? Jan 27 21:20:04 .join #grub Jan 27 21:22:21 RP: /bin/sh -> bash Jan 27 21:23:04 khem: Its due to the way xz uses CONFIG_SHELL (before automake sets it to its other uses) :/ Jan 27 21:23:23 khem: we can fix that one... Jan 27 21:30:34 I'm trying to switch a recipe to a git repository instead of the tarball so that I can use devtool on the recipe (libnl), but when I try to build it now I get a message that whatever I try can't get it to go through the configure phase. aclocal: error: couldn't open directory 'm4': No such file or directory... I tried with autotool-broken, no luck.... Jan 27 21:31:25 s/broken/brokensep/ Jan 27 21:34:02 JPEW: bigger question - why are we suddenly seeing so many repro build issues? Jan 27 21:34:39 RP: are you thinking of forcing gl_cv_posix_shell ? Jan 27 21:37:00 khem: yes, testing that Jan 27 21:37:11 khem: grep is a bit more of a pain, just sedding that one Jan 27 21:38:02 RP: that will be needed for all packages which use posix-shell.m4 macros I guess these are standard macros coming from m4 Jan 27 21:40:41 come from gnulib https://github.com/coreutils/gnulib/blob/master/m4/posix-shell.m4 Jan 27 21:48:17 RP: peerhap EXTRA_OECONF += "gl_cv_posix_shell=/bin/sh" will do it Jan 27 21:48:55 khem: CACHED_CONFIGUREVARS += "gl_cv_posix_shell=/bin/sh Jan 27 21:56:34 khem: tweaks in -next, retesting Jan 27 21:56:40 RP: I really don't know :( Jan 27 21:57:16 JPEW: I'm not surprised we have some issues, I just don't understand how they all appear now Jan 27 22:05:23 tlwoerner: I think the deploy.bbclass is needed by just about anything that has a do_deploy (precompiled binaries or not) Jan 27 22:05:44 At least, if you want sstate, which you almost always do Jan 27 22:11:47 RP: sounds good, but changes to xz means recompiling everything almost perhaps I should add it to ASSUME_PROVIDED Jan 27 22:12:58 khem: its hard as it means liblzma headers as well Jan 27 22:14:15 RP: Do we run the reproducible test on all AB hosts? Jan 27 22:21:39 JPEW: yes Jan 27 22:21:44 JPEW: well, most Jan 27 22:23:07 RP: my only guess is that the ones we do run it on are "close enough" to similar that it doesn't matter, but the sstate was populated from one of the ones we don't run it on and it's different enough to matter Jan 27 22:24:37 By using sstate, we are effectivly saying that we want reproducible across different hosts. Not that we shouldn't do that, but it's more strict that most other reproduciblity initiatives. Jan 27 22:27:22 JPEW: I just don't understand what changed as sstate is suddenly always bad :/ Jan 27 22:53:45 i figured it out, the patch that implemented the CONFIG item hadn't been applied because it wasn't in my layer. Jan 27 22:58:10 JPEW: yes, i was just using that as one example, sorry for being confusing Jan 27 22:58:51 it just struck me as odd because i hadn't thought about it in depth before: although there's a lot of "stuff" that happens, at the end of the day, very few things make their way to the deploy directory Jan 27 22:59:37 so, in a funny twist, deploying is a non-default case Jan 28 00:28:44 JPEW: when you say "more strict that most other reproduciblity initiatives", I'm curious, what does Debian claim wrt reproducibility across build hosts? Jan 28 00:59:03 i'm trying to make a custom conversion command for an image but i think i'm going about it the wrong way. i tried to add my_conversion_command[depends] += "virtual/kernel:do_deploy" because in my command i want to use the kernel image, but the kernel image isn't deployed. is there any way to make it do that? **** ENDING LOGGING AT Tue Jan 28 02:59:57 2020