**** BEGIN LOGGING AT Thu Aug 29 02:59:57 2019 Aug 29 04:42:55 RP: i am here now, I am on UTC+10 so i just missed your message Aug 29 04:59:49 zeddii:I sent a patch for 5.2 to fix kernel-selftests please include them as well while here, both the patches are backports from mainline https://git.openembedded.org/openembedded-core-contrib/commit/?h=yoe/mut&id=547ace04c06e0bddf0ff2d9bc78e49b5eeec5b4f Aug 29 07:30:31 hi folks! Aug 29 07:31:58 hi chakie . Aug 29 07:32:55 i'm updating a product that we have which is based on yocto to "warrior". Previously we've been using "sumo" and before that some older version. Been working fine Aug 29 07:33:22 Now immediately when I start the bitbake for the image I get: "ERROR: Nothing PROVIDES 'cpio-native'." Aug 29 07:33:50 While googling for the error I saw that there was some talk about it here last year, but I saw no solution. Aug 29 07:35:41 I didn't figure out any way to actually provide the native version of cpio, so I resorted to a "ASSUME_PROVIDED += ' cpio-native '". Aug 29 07:37:11 chakie: it's provided by poky/meta/recipes-extended/cpio/cpio_2.12.bb Aug 29 07:37:15 That made the error go away (yay!) and successfully built the image (yay!) as well as the SDK (yay!). However, the builds were not complete as there are no u-boot.img, boot.bin and similar files actually generated Aug 29 07:38:04 I saw no errors anywhere, but the build simply didn't produce what it was supposed to do when I compare to what the sumo version did. Aug 29 07:38:44 I did try to add dependencies to various versions of "cpio" all over the place, but nothing seemed to have any effect on the error. Aug 29 07:40:07 chakie: could you try "bitbake-layers show-recipes cpio-native"? Aug 29 07:40:27 yes Aug 29 07:41:27 NOTE: Starting bitbake server... Aug 29 07:41:28 WARNING: Host distribution "neon-18.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Aug 29 07:41:30 Loading cache: 100% |######################################################################################################################################################################################################################################| Time: 0:00:00 Aug 29 07:41:31 Loaded 3327 entries from dependency cache. Aug 29 07:41:33 Parsing recipes: 100% |####################################################################################################################################################################################################################################| Time: 0:00:02 Aug 29 07:41:34 Parsing of 2244 .bb files complete (2243 cached, 1 parsed). 3328 targets, 340 skipped, 0 masked, 0 errors. Aug 29 07:41:55 Hm, that was a bit ugly. But it really shows nothing at all except for the normal "parsing recipes". Aug 29 07:42:18 chakie: no "=== Matching recipes: ===" section at the end? Aug 29 07:42:29 No, that's all Aug 29 07:42:40 Just a: Aug 29 07:42:42 Summary: There was 1 WARNING message shown. Aug 29 07:42:51 (about the distro) Aug 29 07:43:04 do "bitbake-layers show-layers" list the "meta" layer? Aug 29 07:43:33 Yes Aug 29 07:43:57 Trying the show-recipes for "cpio" gives: Aug 29 07:44:00 === Matching recipes: === Aug 29 07:44:01 cpio: Aug 29 07:44:03 meta 2.12 Aug 29 07:44:07 Thanks for those progress bars. I will save those for later. *tongue-in-cheek* :p Aug 29 07:44:16 sorry... Aug 29 07:44:17 :) Aug 29 07:44:48 To my defense I haven't been on IRC for 10 years. Aug 29 07:44:59 and poky/meta/recipes-extended/cpio/cpio_2.12.bb has BBCLASSEXTEND = "native" at the bottom? Aug 29 07:45:50 Let me see Aug 29 07:46:43 find chugs along Aug 29 07:47:24 chakie: pro tip: use ag (a.k.a. the silver searcher) instead of grep and fd instead of find. Aug 29 07:47:36 yes, it ends with: Aug 29 07:47:38 BBCLASSEXTEND = "native" Aug 29 07:48:57 Then I don't really know what's going on. :( Aug 29 07:50:46 What would be a good variable to add the dependency to? Aug 29 07:50:51 EXTRA_IMAGEDEPENDS? Aug 29 07:51:55 I would try to find what's causing this weird stuff instead of finding some way to make it work anyway Aug 29 07:52:14 chakie: my suggestion would rather be to find out what pulls it in and trace from there backwards. Aug 29 07:52:22 cpio-native should be there, you shouldn't need to use ASSUME_PROVIDED Aug 29 07:52:40 yeah, it's a pretty fundamental thing Aug 29 07:53:35 we do (for some reason I don't know) have a cpio_%.bbappend that contains BBCLASSEXTEND = "nativesdk" Aug 29 07:53:39 ha! Aug 29 07:53:56 that of course clobbers the "native" in the actual recipe Aug 29 07:54:22 yeah... Aug 29 07:54:24 ffs Aug 29 07:55:00 Er, right :) Aug 29 07:55:39 Maybe use BBCLASSEXTEND_append = " nativesdk" instead Aug 29 07:55:49 Yes. Aug 29 07:55:56 I never noticed that before Aug 29 07:56:45 I've cursed at this for a while now. Thank you for guiding me to finding the problem Aug 29 07:57:48 LeoThe2nd: it got pulled in by the script that builds final images. Aug 29 07:58:01 chakie: :-) glad you found it Aug 29 08:01:00 LeoThe2nd: damn ag is fast... Aug 29 08:01:14 chakie: i know. Aug 29 08:01:27 hence the tip :) Aug 29 08:02:59 LetoThe2nd: I didn't know about fd, I'll try this one :) Aug 29 08:03:10 thanks for that too. recursive grep is so slooow Aug 29 08:03:27 qschulz: have fun! Aug 29 08:03:44 when you can't install ag (non-root etc..) git grep is already A BIG step forward :) Aug 29 08:05:44 qschulz: "non-root"? what does this mean? :P Aug 29 08:11:04 LetoThe2nd: while we're at it. I can't connect over ssh without using mosh now. SO convenient. Aug 29 08:11:49 qschulz: yeah i know about mosh, but i usually just stick to standard ssh-into-shell-with-tmux Aug 29 08:13:15 it just recovers nicely from unstable connections. I've one session open at all times on my laptop, survives suspend/resume and network switches. Very happy about it :) (i'm still using screen though after it) Aug 29 08:13:42 maybe need to try it again some time! Aug 29 08:15:52 only annoying thing about it is that you need to open a big range of ports or know how many sessions max you'll have open at one time Aug 29 08:18:48 ag did a search through my build directory in 30s while i'm building an image. pretty impressive, considering this is some laptop garbage ssd Aug 29 08:20:53 chakie: the trick is that i 1) pully exploits threads 2) skips anything not instantly appearing as text searchable, e.g. any binaroes. Aug 29 09:15:33 nrossi: I thought timezones may be tricky Aug 29 09:15:53 nrossi: it was just to follow up on the email discussion and see how best to move forward Aug 29 09:55:47 RP: was just having dinner, you still around? Aug 29 09:56:07 nrossi: yes Aug 29 09:56:40 nrossi: I'm still trying to wake up, caffeine isn't working today :/ Aug 29 09:57:15 RP: so I tried to see if i could get the gcc/g++ part of the test suite into the gcc-runtime execution. and that seems to work well. For binutils i imagine the only solution there is to create a testsuite recipe Aug 29 09:58:38 with the binutils-cross recipe stashing the build directory like gcc-cross/gcc-runtime does Aug 29 10:00:02 nrossi: ok, I think we'll probably need to do that. "target" dependencies cause huge problems for the cross recipes Aug 29 10:00:26 nrossi: I'm relieved the gcc runtime part works! Aug 29 10:01:11 RP: i did find a bug though when I ran the gcc testsuite in gcc-runtime, specifically with gcc plugins.... i guess there are no users of gcc plugins in oe? Aug 29 10:01:33 nrossi: probably not, no. I think there was a recent patch related to that? Aug 29 10:03:05 RP: how old? cause the issue is that staging rewrite the configargs.h file in the recipe sysroot, which causes issues with the compiler configure args check at plugin load time Aug 29 10:05:06 nrossi: I'm probably thinking of http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1dc2823d62b253a6f7d05f71426f77925523de49 as there were comments made about plugins at the time too Aug 29 10:05:26 nrossi: I've not heard of a configargs issue before Aug 29 10:06:12 RP: interesting... essentially its the value you get when you run gcc -v Aug 29 10:06:35 RP: I haven't checked the gcc code itself, but it appears to sanity check that vs what the plugin was built against Aug 29 10:08:22 nrossi: I suspect there are build reproducibility issues in here too Aug 29 10:09:28 RP: likely, i think it would probably be something solved by rewriting the configargs.h that is used to compile gcc as well as what it installed into the sysroot with dummy paths. Similar to was you see when running gcc -v on a "normal" host distro Aug 29 10:10:14 nrossi: yes, sounds like a plan, either target paths, or paths with placeholders for the OE build path Aug 29 10:11:02 RP: ok, I will look into getting a patch for that. Aug 29 10:11:20 nrossi: did you understand the issue with the oeqa result logging? Aug 29 10:11:33 nrossi: still not 100% sure I have a good solution to that :/ Aug 29 10:11:38 RP: sort of, that was the next questions i have Aug 29 10:12:15 RP: firstly, the selftest/cases location... does it make sense to move it into a new module or does it make more sense to start decorating testcase classes with "categories" Aug 29 10:12:45 nrossi: I've been giving it a bit more thought and realised we do already have some selftests we run on a per machine basis Aug 29 10:13:15 nrossi: here: https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/975/steps/8/logs/step3d Aug 29 10:13:17 RP: i did initial mimic the gotoolchain.py testcase... i assume that is one of the selftest cases that are machine dependent? Aug 29 10:13:28 nrossi: we've kind of sleepwalked into this :/ Aug 29 10:14:36 nrossi: the two we run as machine specific are runqemu and meta_ide. You're right and go should be on that list though Aug 29 10:16:27 RP: so what stops them from being run in default oe-selftest builder? Aug 29 10:16:28 nrossi: I'm now wondering if we split these into two classes, or mark the tests up somehow or quite what to do Aug 29 10:17:01 nrossi: nothing. As I said, we just kind of accidentally ended up here without thinking Aug 29 10:17:27 nrossi: I'm just realising we need to do something about this rather than a hardcoded list in the autobuilder config Aug 29 10:18:04 RP: ok, just making sure im not overlooking big pieces of config :). Aug 29 10:18:11 nrossi: A lot time ago we did talk about "tagging" tests, e.g. "fast" or "slow" or in this case "target" Aug 29 10:18:29 nrossi: Perhaps we should create some decorators for the tests and do that this way? Aug 29 10:18:48 RP: that is exactly along the line of what i was thinking Aug 29 10:19:02 nrossi: that would make your tests work as is and just need some extra code to get access to the markup from the commandline Aug 29 10:19:23 RP: unfortunately the base unittest in python does not have a test category function. But not hard to implement Aug 29 10:21:35 nrossi: wouldn't be the first time we've had to extend it :/ Aug 29 10:22:54 RP: probably making the decorator work on a per class or per method yer? so you can mark the individual test methods as fast/slow/etc. Aug 29 10:23:10 nrossi: yes Aug 29 10:25:17 I am just starting out with Yocto for a new project of ours, and I am slightly confused. If I bring in a layer to my bblayers.conf file, will all recipes in that layer be downloaded and built when I bitbake an image, or only the parts that the image specifies will end up on my rootfs? Aug 29 10:27:25 RP: ok, so the for the results part. I tried to keep it simple to make sure it was in the right direction. But you mentioned injecting the test result differently? Since all the tests are not explicitly runtime tests I was not sure if there was a good way to log them Aug 29 10:28:20 iceaway2: only the parts you image specifies generally Aug 29 10:29:29 nrossi: I thought I'd said the results injection was fine? Aug 29 10:30:41 nrossi: my main thoughts now would be on the namespaces so we can make best use of the current result handling Aug 29 10:32:48 RP: by namespaces are you referring to putting the subtest results into a nested results hierarchy of some sort? Aug 29 10:34:04 nrossi: we generate these reports from the results: https://autobuilder.yocto.io/pub/non-release/20190828-6/testresults/testresult-report.txt Aug 29 10:34:31 nrossi: so if for example we injected as a pretend ptest, it would show up in the ptest table Aug 29 10:35:26 nrossi: I'm not sure that is a good or a bad idea, just thinking what makes sense right now Aug 29 10:36:28 nrossi: we could inject that as ptestresult.gcc-cross for example Aug 29 10:37:00 nrossi: when we implement better refgression analysis in resulttool, it would then work for these "for free" Aug 29 10:37:40 RP: ok, makes sense, putting them under ptest is fine? not going to cause too much confusion? Aug 29 10:38:10 RP: also should it seperate the suites, e.g. "gcc", "g++", "libatomic"... "gas", "ld".... Aug 29 10:38:47 RP: and if so, should they be just the suite or e.g. "gcc.gcc", "gcc.libatomic" Aug 29 10:39:43 nrossi: I think we want to separate the suites where we can as the results are more meaningful Aug 29 10:40:47 nrossi: it may need to become gcc-libatomic as I'm not sure we support nesting that namespace to sublevels Aug 29 10:40:47 or just libatomic I guess Aug 29 10:41:39 RP: I will do the "-" so that its clear what package its from. I think that covers my questions I will get crackin on these things :) Aug 29 10:42:52 RP: oh, before i forget, did you have any issues with the glibc-testsuite implementation? or did that make sense from a review standpoint? Aug 29 10:44:46 nrossi: good question, not sure I looked closely at that :/ Aug 29 10:46:35 RP: have a look when you get a chance, i will still be around for another 4 hours or so :) but just going afk for 10 minutes now Aug 29 10:47:01 nrossi: Looks basically good to me. I just don';t like the BUILD_TEST_ namespace Aug 29 10:48:13 RP: i think TEST_* is what the testimage class uses, does that make more sense? Aug 29 10:48:51 nrossi: these are used by glibc, gcc, anything else? Aug 29 10:49:36 RP: they are just used in the recipe for glibc-testsuite and gcc*. They can be any prefix really Aug 29 10:50:22 nrossi: I'm tempted to suggest TOOLCHAIN_TEST_ Aug 29 10:51:08 nrossi: also, I think if the tests move out the cross recipe, we hopefully don't need the gcc-common change. I think adding in a target dep there on RECIPE_SYSROOT may cause problems Aug 29 10:51:08 RP: ok, will change them to that :). Aug 29 10:51:40 nrossi: running the selftest sstate sigs tests would show that up Aug 29 10:52:21 RP: the gcc-common change is needed so that the extracted builddir has the right paths... Aug 29 10:52:54 nrossi: ok, I wondered if that was the case Aug 29 10:53:16 nrossi: we'll need to run the sigs tests, see if they do show issues Aug 29 10:54:46 RP: I could change is to that only gcc-runtime uses a modified extract function? How do i run sigs tests? Aug 29 10:55:23 "is to" -> "it so" Aug 29 10:59:35 nrossi: oe-selftest -r sstatetests Aug 29 10:59:45 nrossi: lets see if there is a problem or not Aug 29 11:09:07 zeddii: I have the multilib ca-certs issue figured out FWIW, that one isn't kernel Aug 29 11:11:15 Hm, I rebuilt everything from scratch but still got no u-boot.img or boot.bin images Aug 29 11:11:47 Have the image names changed since sumo? Aug 29 11:15:27 In sumo I got a few files like: .build-sumo/build/tmp/work/zedboard_zynq7-poky-linux-gnueabi/u-boot-xlnx/v2018.01-xilinx-v2018.1+gitAUTOINC+949e5cb9a7-r0/package/boot/u-boot.img Aug 29 11:15:48 Same for boot.bin and others. Now no files with those names. Aug 29 11:33:38 I struggle a bit to figure out how the DISTRO variable will affect my build output etc. We are building a custom board around a SOM from Variscite which has a NXP i.MX 8X CPU. Variscite/Freescale provides in their example a distro called "fsl-imx-wayland" and an image called "fsl-image-gui". We do not need any GUI stuff, and I would like to start out as small as possible and later add the extra packages Aug 29 11:33:45 that we need. Now I am a bit confused whether I should keep the distro, and start from a "core-image-minimal", or if I should change the distro to "poky" and use "core-image-minimal". It's difficult for me as a newcomer to understand what implications changing the DISTRO has. Currently I have at least successfully build and booted an image based on "poky" and "core-image-minimal". Aug 29 11:41:57 Does anyone know if submissions to the YP Summit 2019 call for papers should be as attachments to the e-mail or in-line? Aug 29 11:43:38 We will take either Aug 29 11:43:50 preferably in a free format ;) Aug 29 11:44:03 but we can deal Aug 29 11:44:11 lol Aug 29 11:44:23 understood :) Aug 29 11:49:56 Meh, figuring out where the boot and fs images would come from and why they don't come from there isn't trivial at all Aug 29 11:52:48 chakie: what Xilinx machine are you targeting? In general, I've found some of their targets don't include things like boot.bin as part of the boot files list. Aug 29 11:53:39 zedboard-zynq7 Aug 29 11:55:15 This is a setup that's been ok for a few years and a few versions of Yocto, but now with warrior I see some issues. Probably something that has been overridden somewhere either in our conf or the xiling bsp Aug 29 11:55:26 "xilinx" Aug 29 11:56:55 chakie: I see. The last build I have for that target was back on thud, so I'm afraid I won't be much of a help. It might be worth standing up both build environments and comparing "bitbake -e" outputs. Aug 29 11:57:12 iceaway: if you are not using GUI I'd switch to Poky distro Aug 29 11:57:36 chakie: are the boot.bin, etc. in your deploy directory, but not on the SD card (assuming you're using MMC)? Aug 29 11:57:41 I see "IMAGE_BOOT_FILES += "boot.bin uEnv.txt ${KERNEL_IMAGETYPE}-zynq-zed.dtb"" Aug 29 11:58:20 goodwin: they are nowhere in my entire tree. Aug 29 11:59:27 goodwin: in this case we later take the images, move them to developers, extract the images, add in lots more sw compiled using the created sdk, packaged back to an image and then deployed Aug 29 12:03:17 chakie: at a glance between thud and warrior of the machine config, I'm not seeing anything that would prevent those two from being built. Aug 29 12:03:37 Have you tried "bitbake virtual/boot-bin"? Aug 29 12:03:59 (I'm mainly curious if it'll complete without executing anything as if it's already built) Aug 29 12:05:24 Let me see Aug 29 12:05:47 I looked at "bitbake -e" to see if it referenced "u-boot.img" at all and found: Aug 29 12:05:50 IMAGE_BOOT_FILES="uImage zImage u-boot.img zynq-zed.dtb boot.bin uEnv.txt uImage-zynq-zed.dtb" Aug 29 12:05:52 UBOOT_BINARY="u-boot.img" Aug 29 12:06:15 So the environment "knows" about what it should produce Aug 29 12:07:11 goodwin: huh, doing "bitbake virtual/boot-bin" started fetching/building u-boot stuff Aug 29 12:07:24 Sure, but if nothing is depending (RDEPENDS) on the package that provides those files, then they won't be available at runtime. Aug 29 12:07:29 So something is now broken in out setup Aug 29 12:07:36 "our" Aug 29 12:07:42 Did you modify EXTRA_IMAGEDEPENDS at all? Aug 29 12:08:13 The machine has that defined with "virtual/boot-bin", so once you build an image, it should have also built that package. Aug 29 12:08:46 sounds logical Aug 29 12:09:30 (also has virtual/bootloader, FWIW) Aug 29 12:09:39 There is "EXTRA_IMAGEDEPENDS_remove = "u-boot-zynq-uenv"" Aug 29 12:10:13 A comment says it introduced some license issues. But then there should be some other u-boot depended upon somewhere else, right? Aug 29 12:13:09 That recipe only builds out a uEnv.txt file for the SD card that maps to the various file names for your target (kernel, dtb, etc.) Aug 29 12:13:21 "bitbake -e" says "EXTRA_IMAGEDEPENDS=" u-boot-zynq-uenv"" Aug 29 12:13:45 ok, so that's not what makes the real images? Aug 29 12:14:54 That's funny. I would read the comments above that line to see what all is adding/removing. That variable not having virtual/boot-bin, etc., is why it's not being built for your image. Aug 29 12:15:17 If you have a pastebin of your -e output, I would be happy to look at it. Aug 29 12:16:52 It's 1.4MB Aug 29 12:18:21 Let me upload it somewhere Aug 29 12:22:36 I have lots to learn about debugging this stuff... Aug 29 12:23:53 mckoan: thanks that was my initial thought as well. Coming from a previous project using buildroot yocto seems quite a bit more complex. I was thinking of also creating our own distro (based on poky, not sure if we need our own distro though?) and image based on core-image-minimal. If I have understood things correctly, we should create our own layer meta-whatever and keep our customizations there, to make Aug 29 12:23:59 it easier to share between developers (as opposed to having everything in local.conf). Aug 29 12:24:17 * zeddii wakes up to have someone informing him of how virtual/kernel is used. Aug 29 12:24:18 nice. Aug 29 12:25:09 chakie: Did you modify the zedboard-zynq7.conf? Your environment says it only adds u-boot-zynq-uenv vs. the other lines I see here: https://github.com/Xilinx/meta-xilinx/blob/warrior/meta-xilinx-bsp/conf/machine/zedboard-zynq7.conf#L22 Aug 29 12:26:29 RP: I see your email. A lot of history here, so I'll go from what you have in the email., Aug 29 12:28:09 goodwin: yes, it has been changed a bit Aug 29 12:29:16 goodwin: but those extra dependencies have not been removed though. Aug 29 12:30:10 perhaps something in the xilinx layer has changed that just happened to make us depend on those before. Aug 29 12:30:38 chakie: alright, well from your log, it's only adding that one recipe to that variable and nothing is attempting to remove anything. Aug 29 12:31:15 If you search for "EXTRA_IMAGE_DEPENDS [3 operations]" you'll see it calls out line 19 of your machine conf as where it adds that one recipe, and nothing else changes it. Aug 29 12:32:00 BTW if you copied the machine to your new layer (rpd?), you should probably rename it. Aug 29 12:32:45 I didn't set this up, so I'm not exactly sure why things were done the way they were. Aug 29 12:32:45 (i.e., define a new machine entirely) Aug 29 12:33:15 That is perhaps a wise way to go Aug 29 12:33:24 I understand. That log is showing that it's pulling in meta-rpd/conf/machine/zedboard-zynq7.conf vs. the meta-xilinx-bsp one Aug 29 12:33:28 And to actually understand what happens... Aug 29 12:35:53 goodwin: but you mean that this is never actually executed: EXTRA_IMAGEDEPENDS_remove = "u-boot-zynq-uenv" Aug 29 12:36:06 Where is it written? Aug 29 12:36:16 I also saw in that environment that it was only added to Aug 29 12:36:18 (and no, according to your log it never gets picked up) Aug 29 12:36:52 it's in the root recipe that we build Aug 29 12:37:07 a "rpd-base-image.bb" Aug 29 12:37:19 ahaha. RP. now I know why I didn't see the eudev build issue. Aug 29 12:37:31 ERROR: Nothing PROVIDES 'eudev' Aug 29 12:37:32 eudev was skipped: conflicting distro feature 'systemd' (in DISTRO_FEATURES) Aug 29 12:38:08 It basically inherits core-image, adds some extra packages and removes some unwanted ones Aug 29 12:39:56 chakie: ah. Well if you ran "bitbake -e rpd-base-image", I would expect to see the _remove show up. Aug 29 12:41:03 chakie: also, I'm not sure that making changes to that variable in an image definition is really fitting with the intent of that variable: https://www.yoctoproject.org/docs/2.6.2/mega-manual/mega-manual.html#var-EXTRA_IMAGEDEPENDS Aug 29 12:41:37 It's a list of packages that are not needed for the rootfs (vs. the image defining what goes in the rootfs) Aug 29 12:42:01 RP: but yet lttng-ust build here for qemuppc. hmm. I'll dig more. Aug 29 12:42:47 goodwin: yeah, now I see the remove and it's left empty Aug 29 12:44:51 From what I can grok, we used to get a dependency on "virtual/u-boot" or similar with the sumo versions of our layers, but now don't Aug 29 12:45:19 Which means we build an assload of packages that never get used anywhere. :) Aug 29 12:47:46 chakie: Yeah, I'm not sure how that dependency would have changed between sumo vs. warrior unless something is horked up with your bblayers.conf and layer priorities between those two builds (this would end up picking the xilinx -defined machine vs. your meta-rpd one) Aug 29 12:48:33 zeddii: that is odd :/ Aug 29 12:48:50 zeddii: note it was the mpc, not qemuppc Aug 29 12:49:50 I can try that as well. but just switching to sysvinit is going to take about an hour for my builder to recover, so I'll churn away on them as fast as I can Aug 29 12:50:19 * zeddii builds @ home with two servers in his basement, so no corporate build power unfortunately. Aug 29 12:51:13 goodwin: hm, now when I look at the files we have a bit closer it seems that the zedboard-zynq7.conf is never updated based on new changes, it's been like that for years Aug 29 12:52:50 RP: the one I find the most odd is the qemuarm /dev/fb0 one. I was building and booting that constantly. So I'll dive into the logs while I wait for builds and see if I can spot a difference. Aug 29 12:53:30 zeddii: its possible its some other patch in -next :/ Aug 29 12:53:36 zeddii: it sounds kernel related though Aug 29 12:53:52 zeddii: btw, I think I missed qemumips issues from that email :/ Aug 29 12:53:52 agreed. starting with the kernel is the right thing. Aug 29 12:54:06 hmm. Well, layer order matters in bblayers.conf since that's going to wind up being the set of search paths for recipes, conf files, etc. Since your environment is picking up your meta-rpd -based machine, you should update the EXTRA_IMAGEDEPENDS to include those two virtual targets so it'll build them with your image. Aug 29 12:54:16 RP: zeddii: I wonder if the /dev/fb0 is this http://git.yoctoproject.org/cgit.cgi/poky/diff/meta/conf/machine/qemuarm.conf?h=master-next&id=e097cdcadc6a6a5afdbd799ce3f9c65b5bacf780 Aug 29 12:54:27 bugger. I build qemumips/mips64 for all the images I could think of. Aug 29 12:54:27 still, as far as Aug 29 12:54:27 It's that or you'll have to manually build virtual/boot-bin and virtual/bootloader ahead of building your image(s). Aug 29 12:54:31 lib64-packagegroup-core-device-devel-1.0-r1 do_populate_lic - 2h53m1s (pid 8842) Aug 29 12:54:34 that sounds wrong Aug 29 12:54:39 (so that the files will exist in the deploydir) Aug 29 12:55:04 RP: and if yous eee alex's follow up. I missed a kernel feature in my recipe copy. so I bet that is the fb0 thing. Aug 29 12:55:05 goodwin: yeah, I added them to EXTRA_IMAGEDEPENDS and building right now Aug 29 12:55:10 s/eee/see/ Aug 29 12:55:12 as far as I understand, -device VGA,edid=on is equivalent to -display vga, and -display vga is actually the default, so it doesn't need to be specified explicitly Aug 29 12:55:23 yeah, maybe the missing drm-bochs bit also plays a role Aug 29 12:55:38 I'll deal with the root cause of me dropping that, once we are green with 5.2. Aug 29 12:56:10 zeddii: ok, are you going to send some more patches and we can retest? Aug 29 12:56:24 goodwin: ok, now I got all the image files except a uImage-zynq-zed.dtb Aug 29 12:56:31 RP: yes. do you want new versions or follow on patches. I can easily do either flow. Aug 29 12:57:16 zeddii: may as well do follow on and let me know if anything should be squashed Aug 29 12:57:32 zeddii: I have Kevin's BSP uprev to add in the next round which may help mpc Aug 29 12:59:20 chakie: It looks like your machine adds that name to IMAGE_BOOT_FILES, which ultimately ends up containing zynq-zed.dtb and uImage-zynq-zed.dtb (the former is added by xilinx's machine-xilinx-default.inc according to your env file). Aug 29 13:00:10 chakie: Do you have a package that installs uImage-zynq-zed.dtb to the deploydir? Aug 29 13:01:37 RP: works for me. I'll just keep stacking changes, and can put in the temp section where it can be squashed. Aug 29 13:01:57 * zeddii deals with follow ons better than new revisions when merging as well Aug 29 13:02:32 goodwin: to build/tmp/deploy/images/zedboard-zynq7? Aug 29 13:04:03 chakie: right. If you have a package that builds that file (and inherits from deploy, etc.), then similar to before, you can add it to the machine's EXTRA_IMAGEDEPENDS too so that it implicitly gets built (the rest of your config like KERNEL_DEVICETREE seems to imply you're also using the one from the virtual/kernel package) Aug 29 13:05:00 chakie: so unless you don't want that device tree blob as well, you should probably remove the zynq-zed.dtb from IMAGE_BOOT_FILES list in your machine as well. Aug 29 13:05:01 RP: I tracked down the getty fast fail problem. systemd is ever changing... Aug 29 13:05:12 It only happened on a first boot. Aug 29 13:05:34 love those kind of ones. means constantly copying images or rebuilding new ones. Aug 29 13:05:36 And even then, not all the time, as it is a udev/systemd race. Aug 29 13:05:39 jwessel: ah. Glad we're not imagining it then :) Aug 29 13:06:02 That is why I copied the image the one time I saw it. Aug 29 13:06:03 goodwin: our scripts that grab the built files seem to expect that dtb file. Aug 29 13:06:06 zeddii: qemu can do COW Aug 29 13:06:10 I figured it must be something super odd. Aug 29 13:06:36 jwessel: runqemu should only ever work off a copy and hence be a first boot Aug 29 13:06:40 I am reading the latest systemd foo in order to figure out a different way to use it, hopefully without patching the code. Aug 29 13:06:48 jwessel: hence the 100% autobuilder hit Aug 29 13:07:00 ~. Aug 29 13:07:33 But runqemu makes a copy only the first time. Statistically autobuilder was going to hit it more often because of that. Aug 29 13:07:52 second boot, as far as I can tell never will hit it, because udev is running much earlier. Aug 29 13:10:16 In the systemd in thud, it was fine to use the BindsTo=... Aug 29 13:10:20 Now it has to work like this: Aug 29 13:10:28 PartOf=dev-%i.device Aug 29 13:10:28 ConditionPathExists=/dev/%i Aug 29 13:10:28 After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service Aug 29 13:10:46 So for the ttyUSB0 transient device case we get: Aug 29 13:10:49 Aug 29 13:09:05 qemux86-64 systemd[1]: Condition check resulted in Serial Getty on ttyUSB0 being skipped. Aug 29 13:12:14 chakie: tgoodwin: zynq-zed.dtb is the proper name for the dtb, uImage-...dtb is no longer produced by the kernel see (http://git.openembedded.org/openembedded-core/commit/?id=1860d9d3c62e2e94cd68a809385873ffd8270b6d) Aug 29 13:12:15 At least we didn't have to patch systemd... Aug 29 13:12:26 chakie: alright. Looking at the history of meta-xilinx, it looks like it used to be called ${KERNEL_IMAGETYPE}-zynq-zed.dtb and then the moved it all up into that machine include file as a function. Aug 29 13:13:44 nrossi: beat me to it. Aug 29 13:13:47 thanks ;) Aug 29 13:15:50 chakie: it looks like that function (get_default_image_boot_files) then received another tweak to do what nrossi pointed out, which is no longer prefix KERNEL_IMAGETYPE to the KERNEL_DEVICETREE name(s). Aug 29 13:16:15 https://github.com/Xilinx/meta-xilinx/commit/f20fc414f30803c126bea4222d9fb2bb73c2b07f#diff-ac06f14aea5b3b57632e015f5cd3821e Aug 29 13:16:58 goodwin: aha, our scripts expected the image type to be prefixed. Aug 29 13:17:32 No worries there, easy fix as zynq-zed.dtb is generated just fine. Aug 29 13:17:39 chakie: yeah, at least we've identified you don't have some other package providing that other name :) Aug 29 13:17:54 New news from stackoverflow: updating nodejs on linux (yocto) using npm Aug 29 13:20:48 goodwin: no, but we do have a small mess that has seen some bit rot :) Aug 29 13:22:52 goodwin: I would never have figured this out without your help... Thank you so much! Aug 29 13:25:42 chakie: you're welcome :) Aug 29 13:38:14 JPEW: reproducibility tests ran on the autobuilder, it wasn't so good :/ Aug 29 13:38:53 JPEW: https://paste.debian.net/1097867/ Aug 29 13:39:04 JPEW: I might have found the ca-certs one Aug 29 13:49:01 RP: Yep, those look like the usual suspects Aug 29 13:49:37 Well, except for the kernel module Aug 29 13:51:41 iceaway: yes, you are right Aug 29 13:52:36 RP: gah. on my builder the ppc neard issues doesn't show up. that's two now that I can't reproduce. Aug 29 13:52:57 I was using musl in that config. but really, that should hurt, not help. Aug 29 13:53:10 TARGET_SYS = "powerpc-poky-linux-musl" Aug 29 13:53:10 MACHINE = "mpc8315e-rdb" Aug 29 13:53:10 DISTRO = "poky" Aug 29 13:53:30 aaaaaand eudev just built for the mpc as well. Aug 29 13:54:46 zeddii: could be a musl vs glibc difference? :/ Aug 29 13:55:06 JPEW: so they're known issues? Aug 29 13:55:08 I just switched to glibc and started again. I'll know soon. Aug 29 13:57:35 RP: They look familiar... I think those might be the ones that have trouble passing without doing 2 clean builds (it was a while ago, so I don't remember exactly). Aug 29 13:58:25 RP, thanks for the information from the autobuilder. Aug 29 13:58:57 I sent a new v2 of the getty fast-fail patch, which is tested specifically against u-dev race that was found. Aug 29 13:59:02 RP: The doc ones are almost certainly because of pod2man in HOSTTOOLS Aug 29 13:59:40 I also re-tested against the hardware states of having the usb device in, out, plugged in after boot, and unplugged after boot to make sure the behavior was all still consistent. Aug 29 14:01:24 RP: ACL is probably also because of HOSTTOOL paths changing (coreutils mostly) due to rebuilds with RSS, and perl-ptest.... is just a mess :) Aug 29 14:10:27 this is my swupdate-image.bb file: https://paste.fedoraproject.org/paste/f7mqdGibVsaBCWGXwFmyIQ Aug 29 14:10:50 what is the "bb.utils.contains" function on line 13? Aug 29 14:12:50 if SWUPDATE_INIT contains tiny then initscripts-swupdate else initscripts sysvinit Aug 29 14:13:09 https://github.com/openembedded/bitbake/blob/master/lib/bb/utils.py#L963 Aug 29 14:13:25 zeddii: meta-openembedded also shows some failures with 5.2 headers see https://errors.yoctoproject.org/Errors/Build/87788/ Aug 29 14:14:28 klibc linux-atm can-util qtserialbus qtwebengine Aug 29 14:15:11 khem: yep, I knew there would be failures, given that I had to fix packages for the tweaked y2038 headers, but I'm tapped out on cycles at the moment. Aug 29 14:15:20 error: use of undeclared identifier 'MAP_PRIVATE' Aug 29 14:15:24 RP: I can reproduce none of the autobuilder failures. Aug 29 14:15:45 I just built lttng-ust, neard and eudev for the fsl_mpc Aug 29 14:15:47 is MAP_PRIVATE gone ? Aug 29 14:16:19 it may have moved. /me goes to check. Aug 29 14:16:44 ha ha. /me Aug 29 14:16:54 other issue is error: use of undeclared identifier 'SIOCGSTAMP' which is trivial to fix Aug 29 14:16:59 qschulz: thanks! Aug 29 14:17:09 yah. that was was littered in a few packages. Aug 29 14:18:09 I just have NFI how I can be building the packages fine that the autobuilder couldnt Aug 29 14:18:34 no financial information? Aug 29 14:19:24 zeddii: not good :( Aug 29 14:19:56 I'm switching to your master-next with none of my local changes and will try that. Aug 29 14:20:52 I'm sure none of them are that hard, if I can just reproduce them. I had to fix a lot during the early days after I bumped the headers. Aug 29 14:22:25 zeddii:btw. musl version in oe-core does have 5.2 fixes so it is possible that something will build with musl but not glibc Aug 29 14:35:06 Goodday, I'm currently trying to find the best way to deal with device tree overlays. I basically want to use u-boot to load overlays over the base device tree, the only problem is that the base devicetree (that will be built by kernel-devicetree) does not use the "-@" flag for dtc, and thus there are no __symbols__ in the blob which u-boot needs. My workarround currently is to clear KERNEL_DEVICETREE and add a recipe file which inherits Aug 29 14:35:08 from devicetree. Within this recipe I build the base devicetree and all the overlays (I can overrite DTC_FLAGS which is used by devicetree.bb). I was wondering if there might be a better solution to that problem ;) Aug 29 14:36:10 A soluition that would work with KERNEL_DEVICETREE Aug 29 14:38:54 <__angelo> hi :) have an image with a DEPENDS += "another_image" but seems the build of "another_image" is not triggered Aug 29 14:45:44 Hi all, I'm trying to build a node.js package with Yocto (rocko) according to https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM. I finally succeed building the example cute-files, but when I go with my own package its fails with "Exception: RecursionError: maximum recursion depth exceeded in comparison" (it seems) during dependencies research. Does someone already have similar issue? Aug 29 14:49:29 bisbarn: when I manually compiled the kernel for DT overlays, I made those two patches: https://github.com/QSchulz/linux-at91/commit/deff47fd469863f301b452a6c853fb803af7170d https://github.com/QSchulz/linux-at91/commit/c1ddbd31090bc8d82d5df38af2a12e8c053bb01f Aug 29 14:49:38 maybe you can apply those to your kernel Aug 29 14:52:59 __angelo: here we have do_rootfs[depends] += "foo-image:do_build" Aug 29 14:53:27 <__angelo> qschulz, oh thanks Aug 29 14:53:32 qschulz: that should work, I'll give it a try tomorrow, thank you ;) wondering why they haven't added a config option to enable building the devicetrees with symbols to the kernelconfig :) Aug 29 14:54:50 Honestly I don't know, they have changed already a few times the format of device trees,nothing's fixed yet AFAIR Aug 29 14:54:59 might not even be -@ anymore Aug 29 14:55:20 well atleast with 4.9.13 it still is ;) Aug 29 14:55:36 and you need dtc > 1.14 from what I recall, directly in the kernel sources Aug 29 14:55:53 yeah Aug 29 14:56:06 but I guess 4.9.13 should come with dtc 1.14 ;) Aug 29 14:56:57 __angelo: of course a dependency from an image can make sense only as runtime so it should be a kind of RDEPENDS Aug 29 14:57:02 well, the patch I sent you is for 4.9 (I don't know the dot) Aug 29 14:58:21 mckoan: it's a bit trickier I think. There is a task dependency behind DEPENDS and RDEPENDS Aug 29 14:58:50 image recipes are different and i honstely don't know if they have those tasks or if something is done in there Aug 29 14:59:11 so one task depends on a task which is empty or never executed or so, basically a no-op Aug 29 14:59:35 e.g. https://www.yoctoproject.org/docs/2.6.3/ref-manual/ref-manual.html#var-RDEPENDS: This dependency is from the recipe's do_build (not to be confused with do_compile) task to the do_package_write_* task of the recipes that build bar and baz. Aug 29 15:08:24 bisbarn: FYI, only since 4.11 Aug 29 15:09:45 <__angelo> mckoan, tested also RDEPENDS, not working for mw Aug 29 15:19:17 <__angelo> qschulz, oh, seems do_rootfs[depends] is also not working. Shoudl i cleanall ? Aug 29 15:24:57 YP bug triage over Aug 29 15:31:04 RP: no sstatetests failures with the gcc-common change Aug 29 15:31:23 nrossi: ok, great. I'm surprised but that is good Aug 29 15:31:37 RP: Sent clean build patch for reproducible OEQA test Aug 29 15:31:49 JPEW: thanks, I'll rerun it with that Aug 29 15:32:37 RP: also looks like there is already a "tag" decorator in the oeqa core. But i think it works in reverse to how you might want it to work for the toolchain tests Aug 29 15:33:45 RP: the runner filters cases that match the tag Aug 29 15:33:54 __angelo: of course, I didn't say to use RDEPENDS Aug 29 15:33:58 RP: I just can't break any of the packages that blew up for you. Aug 29 15:34:12 nrossi: oh. Do we use that anywhere? Could we add a match option I wonder? Aug 29 15:34:58 RP: it did not appear anywhere in oe-core/meta. So it could just be reversed Aug 29 15:35:11 __angelo: AFAIK is not possble to depend on an image though Aug 29 15:35:16 https://pastebin.com/v7Zesf6r Aug 29 15:35:46 nrossi: very tempted to do that... Aug 29 15:38:36 RP: i will look at doing that then, see if it can work. anyways I am off to bed, will likely have updates for you tomorrow Aug 29 15:40:49 nrossi: thanks, sleep well! Aug 29 15:54:57 <__angelo> mckoan, ooh, so it is not possible to trigger another image from the current ? Aug 29 15:55:04 <__angelo> ok :( Aug 29 15:58:20 heh. even on master next, mpc8315e-rdb, I can build lttng-ust, eudev and neard. time to ponder WTF is going on. Aug 29 16:01:43 RP, sadly, looks like u-boot is not ready for python 3, they need to update several scripts that are used during build Aug 29 16:02:16 I wonder if we can apply pressure for them to get on with it somehow Aug 29 16:18:28 New news from stackoverflow: YOCTO : Where can I find my Linux kernel source directory? Aug 29 16:34:57 kanavin_: I think people like Tartarus are already working on that Aug 29 16:35:21 kanavin_: Ahem, patches welcome. Aug 29 16:35:40 It's not that we're unaware of the deadline, it's that no one has volunteered to help move things along. Aug 29 16:36:50 same old story for all of use Aug 29 16:36:57 Indeed. Aug 29 16:56:03 Hi - Trying to track down Bruce Ashfield these days... anyone know where he is in #yocto or email? Aug 29 16:56:18 scottrif, he's zeddii I think Aug 29 16:56:26 yep Aug 29 16:56:35 and active in oe-core Aug 29 16:56:48 bruce.ashfield@gmail.com Aug 29 17:03:27 khem: thers a patch to libdevmapper one meta-oe thats breaking for me ( 3f64779ea ), I think its because it sets PACKAGES="", am I the only one that has this issue? Aug 29 17:06:52 Thanks! Aug 29 17:08:13 kanavin_, RP, if I build build-appliance-image on master (or warrior..) will that get me something with python==python3 or do I need something more for that? Aug 29 17:08:49 Or is there some other easy way to get myself a development system without python2, so I can see what else is hitting the fan, aside from libfdt horrors Aug 29 17:10:37 Tartarus, the way I am doing it is by mv /usr/bin/python2.7 /usr/bin/python2.7.bogus Aug 29 17:10:49 and patching out python2 from HOSTTOOLS in bitbake.conf Aug 29 17:11:11 What's your starting host? Aug 29 17:11:14 aehs29: how does it break ? maybe carry the discussion on ml ? Aug 29 17:11:29 Tartarus, ubuntu 18.04 Aug 29 17:11:33 OK Aug 29 17:11:35 thanks Aug 29 17:11:51 then you need to adjust the recipe to not require python-native Aug 29 17:12:36 Well, I'm going to be trying to do things in U-Boot itself, just need an env Aug 29 17:12:38 or, actually if you are not using bitbake but building u-boot directly on the host, then simply moving py2 out of the way is enough I guess Aug 29 17:12:50 I know libfdt stuff is going to crap out, which is annoying Aug 29 17:13:14 but I think, aside from genboardscfg.py (which 2to3 + stack overflow got me converting) it might be otherwise "just" changing python2 to python3 in some places Aug 29 17:13:18 Tartarus, I tried PYTHON2=python3, and libfdt was happy with that, but then somewhere else failed Aug 29 17:13:27 Oh? Hmm Aug 29 17:13:36 I'll see what I see soon then, thanks Aug 29 17:13:38 because #!/usr/bin/python Aug 29 17:13:56 khem: shouldve checked the ML before my bad Aug 29 17:13:56 at that point I gave up Aug 29 17:14:57 khem: its actually a different error, but let me check the latest patch, if its still breaking I'll reply to the ML thread Aug 29 17:56:44 __angelo: yes you can, I do it. I did a shortcut. We have a new task which is addtask bar before do_rootfs and then do_bar[depends] += "foo-image:do_build". IIRC. I don;t have access to the code right now though. Aug 29 17:57:08 have you tested each image separately to make sure they work on their own already? Aug 29 18:19:32 <__angelo> qschulz, oh thanks. Yes, images works Aug 29 18:20:17 <__angelo> qschulz, well, if it happens you have a code sample, even similar, would be nice Aug 29 19:01:55 RP: unfortunately, no patches from me today. My day was derailed on not being able to reproduce things, so I just watched builds for the most part. Aug 29 19:02:24 I'm only working a 1/2 day tomorrow, which means mid next week before any significant process can be guaranteed. Aug 29 19:02:53 I'd suggest just dropping the whole thing from master-next, and I can resubmit when / if I can reproduce the failures. Aug 29 19:03:02 zeddii: does it mean significant beer && metal? :P Aug 29 19:03:21 :D beer at least. Aug 29 19:03:25 \m/ Aug 29 19:04:13 * zeddii sees about 200 email that he didn't read today while trying to sort this stuff. So yah, beer now!! I can't stand to dig into it at the moment Aug 29 19:04:28 * zeddii bets he'll get 'ping' email on it tomorrow and will have to not type any hasty responses ;) Aug 29 19:07:10 exactly my life these days. $CUSTOMER is bitching and so i'm currently doing funky js dev on my balcony. beer is involved @ 9pm. Aug 29 19:07:40 this is why we all head to conferences to commiserate and do more beer :D Aug 29 19:08:04 \m/ Aug 29 19:08:08 you @ ELCE? Aug 29 19:08:32 I am Aug 29 19:08:42 nice. so yay for beer. Aug 29 19:08:50 most definitely. Aug 29 19:09:44 i think so far i am the only OE member that has only be accepted under the official premise that i bring along booze to meetups. Aug 29 19:17:15 any suggestions on how to speed up "Parsing recipes" in bitbake? I'm toying with local.conf and it takes several minutes between iterations.. Aug 29 19:17:49 fullstop: are you using multiconfig? Aug 29 19:18:06 considering that I don't know what that is, doubtful. Aug 29 19:18:29 I'm coming from buildroot, so this is all very foreign at the moment. Aug 29 19:19:34 fullstop: ah. you can try removing unnecessary layers. Aug 29 19:19:57 fullstop: take out layers, get ssd, get ram, get fast cpu. in that order, probably. Aug 29 19:20:00 dang, I've already done that. Aug 29 19:20:12 well, removed layers. it's a ssd and fast cpu already. Aug 29 19:21:00 then you must have an extremely rich stack of layers n use, because parsing on my desk machine takes somewhere in the 30-50sec range usually. Aug 29 19:21:02 I don't have all of these resources available to me, but I've got 96GB of memory and a 24 core X5670.. Aug 29 19:21:45 anyway, I guess I'll live with it for now. Aug 29 19:24:07 does everyone have double digits CPU cores? I feel left out Aug 29 19:24:56 this is a server if it makes you feel any better Aug 29 19:25:23 fullstop: aw, i was sooo convinced it is your tablet :/ Aug 29 19:26:36 It wouldn't surprise me if the next generation of snapdragon cpus steps into double digits. Aug 29 19:27:39 hrhr. and with that, I'll call it a day. Aug 29 19:37:28 OK, so, kanavin_, RP, I've kicked things harder. Where we stand is that some of our tools (binman) need some more work, but Simon Glass (author) knows/is on it. Is a problem for some targets such as allwinner. Another script we need, I converted today as 2to3 + stackoverflow got me there. scripts/dtc/pylibfdt/ just needs s/python2/python3/ and that is going on upstream to maybe just be "python", but we'll do Aug 29 19:37:28 something. Aug 29 19:37:56 There's a few other scripts that are python2 but aren't part of the required build, one of which I'm just killing and another needs someone that speak python to figure out Aug 29 19:38:03 there seems to be a known issue with psplash images being shipped as C code without the png source (see http://lists.openembedded.org/pipermail/openembedded-devel/2010-August/144301.html and https://github.com/AsteroidOS/meta-asteroid/blob/master/recipes-core/psplash/psplash_git.bbappend) Aug 29 19:39:45 appart from being annoying when one wants to change the theme, isn't there a problem with the GPL here, as this is clearly not "The source code for a work means the preferred form of the work for making modifications to it" ? Aug 29 19:39:54 i'm confused about the INITRAMFS_IMAGE used in local.conf Aug 29 19:40:40 the docs state that setting this "Causes the OpenEmbedded build system to build an additional recipe as a dependency to your root filesystem recipe " Aug 29 19:41:29 so for example, would setting INITRAMFS_IMAGE "abc" cause an actual .bb file to be generated, abc.bb? Aug 29 19:42:01 "...in an initramfs image named core-image-sato-initramfs.bb to be created" Aug 29 19:43:09 mine is set to 'INITRAMFS_IMAGE = "swupdate-image"' Aug 29 19:43:33 which i thought was running the swupdate-image.bb file /sources/meta-swupdate/recipes-extended/images/swupdate-image.bb Aug 29 19:45:17 is that not the case? Aug 29 19:49:05 the link local.conf.sample.extended referenced in this glossary entry is dead Aug 29 19:49:17 https://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html Aug 29 19:50:33 hello? Aug 29 19:50:46 is this thing on? Aug 29 19:53:46 as i understand it, a cpio.gz file can be provided to the kernel recipe to which specifies the rootfs to use for a initramfs. i am trying to see how those rootfs files are generated so i can add my own init.d script Aug 29 19:56:05 stumped you all? ha! Aug 29 20:02:02 heck with linux. anyone up for some spectral esimation using minimum relative entropy? Aug 29 20:02:09 estimation Aug 29 20:09:11 pretty sure there's a different variable for bundling the initramfs image into the kernel rather than just producing the image binary Aug 29 20:09:19 don't recall the name offhand. INITRAMFS something or other Aug 29 20:09:39 INITRAMFS_IMAGE? Aug 29 20:12:06 kergoth:INITRAMFS_IMAGE_BUNDLE Aug 29 20:12:12 that's the one, thanks Aug 29 20:13:14 and you need to define initramfs image with INITRAMFS_IMAGE Aug 29 20:13:16 INITRAMFS_IMAGE Just builds the initramfs. iirc you could have your bootloader make use of it instead of bundling it into the kernel?, though i don't know why, that'd be more like initrd Aug 29 20:13:21 * kergoth shrugs Aug 29 20:13:48 hmm Aug 29 20:14:23 bootloader just knows about kernel so that remains consistent weather you use initramfs or not Aug 29 20:14:24 as i understand it, modern kernel's ALWAYS create a ram-disk-based rootfs initially: https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt Aug 29 20:14:40 s/kernel's/kernels/ Aug 29 20:14:45 kernel can then bundle an image into itself and boot into it Aug 29 20:15:16 which can then pivot into full user space rootfs Aug 29 20:16:42 kergoth:grub I think can specify external initrd but to me initramfs in kernel seems better approach Aug 29 20:17:01 this is all known. my question is how to customize the rootfs that is bundled into the kernel Aug 29 20:17:19 like i said, i want to add my own init.d script Aug 29 20:17:25 khem: agreed Aug 29 20:17:44 it's just another image recipe from bitbake's perspetive, yates. specify your own image, done Aug 29 20:18:07 but you have to use the bundle variable to get it bundled into the kernel image, and i'm not sure if wic will use the bundled image yet or not Aug 29 20:18:17 last time i looked wic didn't handle it at all Aug 29 20:18:29 wic? Aug 29 20:18:45 yes, it works. i've already built it. Aug 29 20:19:16 but i built a non-customized rootfs Aug 29 20:19:34 i have my INITRAMFS_IMAGE_BUNDLE = "1" Aug 29 20:19:41 i have my INITRAMFS_IMAGE = "swupdate-image" Aug 29 20:20:00 so copy swupdate-image.bb to your own image file and change INITRAMFS_IMAGE to match, and modify it as you would any other image in oe Aug 29 20:24:19 makes sense. right. Aug 29 20:38:29 the existing oe swupdate-image.bb, https://paste.fedoraproject.org/paste/TVvTGPH46ThER9LU6qXsGQ, ... Aug 29 20:38:51 contains a line ${@bb.utils.contains('SWUPDATE_INIT', 'tiny', 'initscripts-swupdate', 'initscripts sysvinit', d)} Aug 29 20:39:26 which currently fails loades 'initscripts sysvinit'. Aug 29 20:40:08 if i just define SWUPDATE_INIT='tiny', then couldn't i j use the oe swupdate-image and put in my own initscripts? Aug 29 20:40:27 via initscripts-swupdate.bb? Aug 29 20:40:57 no, nm Aug 29 20:41:04 that .bb already exists. Aug 29 20:41:31 i'm trying to optimize yocto - bad idea... Aug 29 20:41:46 just copy the damn swupdate-image.bb... Aug 29 20:43:07 new (but related) question: in my standard image recipe i have packages recipes specified in "CORE_IMAGE_EXTRA_INSTALL" but also in "IMAGE_INSTALL_append". what's the difference? Aug 29 21:00:09 the former is only obyeed in the images inheriting core-image, not just image. the latter is obeyed everywhere. the problem with the latter is it's difficult for a recipe to override (i.e. an initramfs recipe can't just set CORE_IMAGE_EXTRA_INSTALL="" to prevent those from installing, so it's more likely to affect images you don't want it to, and it's just more prone to user error. the former is an explicit hook, so doesn't require _apppend vs += Aug 29 21:04:48 ok, thanks kergoth Aug 29 21:04:58 i'm not sure i'm grokking all that, but thanks.. Aug 29 22:20:26 zeddii: any patches for me to put into a new build? Aug 29 22:20:36 Tartarus: sounds like good progress, thanks! Aug 29 22:20:51 Tartarus: I wish I wasn't drowning in release problems or I'd offer to help :/ Aug 29 22:21:23 RP, I appreciate the senitment, thanks. We'll get this sorted before Jan 1 at least I'm pretty sure :) Aug 29 22:22:36 Tartarus: if you do have specific problems I'm happy to look and see if it matches anything I've run into when doing the conversion for bitbake/OE Aug 29 22:22:53 RP: zeddii said to revert them until mid next week IIRC Aug 29 22:23:32 khem: thanks, I'd missed that Aug 29 22:24:21 Will do Aug 29 22:24:52 I cleaned up first lot in meta-oe as well, now there are some hard nuts like klibc where the syscall stub is failing no idea why, its all perl Aug 29 22:25:18 RP: yah. I can reproduce exactly zero of the failures here. Aug 29 22:25:26 so I'm pretty much screwed on userspace fixes. Aug 29 22:25:52 there's minor changes I'll send tomorrow, but I'm simply not able to do anything with the rest. Aug 29 22:26:08 which doesn't surprise me, since I build all those configs before ever sending the series. Aug 29 22:26:10 JPEW: reproducible.ReproducibleTests.test_reproducible_builds: PASSED (7227.98s) Aug 29 22:26:10 JPEW: how curious Aug 29 22:26:48 zeddii: you even tried master-next directly? Aug 29 22:26:53 yup Aug 29 22:26:56 zeddii: this is very weird :/ Aug 29 22:27:12 cleanall on neard lttng-ust eudev -> bitbake. no issues. Aug 29 22:27:30 whats the issue with neard Aug 29 22:28:13 I have to bolt, have to get supper for the kids. Aug 29 22:28:18 khem: on the mpc machine, neard, eudev and lttnf-ust all failed Aug 29 22:28:38 khem: https://autobuilder.yoctoproject.org/typhoon/#/builders/70/builds/976 and https://autobuilder.yoctoproject.org/typhoon/#/builders/70/builds/977 Aug 29 22:28:44 RP: I'm only working a half day tomorrow, and since it is the long weekend .. I won't be back sending patches until middle of next week. Aug 29 22:28:48 zeddii: I reran the build, same errors Aug 29 22:29:20 zeddii: right, ok. I'll switch to hitting other stuff and defer M3 further Aug 29 22:29:38 I'd rather the whole series just be dropped, since I want to rebase and clean things up, since it'll be days before I get to it, and I won't be able to keep is straight. Aug 29 22:29:55 zeddii: can I try and keep the python2 bits? Aug 29 22:30:06 those should be fine. Aug 29 22:30:48 RP: and just as strange. I can reproduce my good builds on two separate machines. so it isn't some uncomitted change I have on my main dev box. Aug 29 22:31:14 like I said, I never would have sent it if something that obvious broke here, so I have no idea what is going on. Aug 29 22:31:22 zeddii: I believe you! Aug 29 22:31:22 all I did was watch builds today. Aug 29 22:31:35 zeddii: there is something we're missing :/ Aug 29 22:31:41 its as if the configs don't match somehow Aug 29 22:32:09 I'll keep trying. I won't resend without some explanation :D Aug 29 22:32:34 zeddii: I guess meanwhile I should see if I can reproduce locally Aug 29 22:32:51 they actually aren't hard to fix. most upstreams have patches avaialble (or debian/gentoo) Aug 29 22:33:07 I just need to see it, google it, import and fix. but I'm failing at step #1 Aug 29 22:33:42 zeddii: right. I was just thinking it would be good to see if someone else can reproduce or not Aug 29 22:33:50 RP: obviously, I'll queue the kernel patches from Kevin, etc, as well, and put them in my next series, since you need my base ones for them. Aug 29 22:34:07 zeddii: right, I just stripped his patch out of -next Aug 29 22:34:35 RP: I don't doubt something funky is going on. I *had* a ppc build error in August. and it was *nasty* Aug 29 22:34:42 zeddii: FWIW beaglebone had WARNINGS: https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/990/steps/8/logs/warnings Aug 29 22:34:47 it has to do with the gcd "fixincludes" Aug 29 22:34:56 gcc fixincludes that is. Aug 29 22:35:08 gcc fixes up the new uapi headers and breaks ppc Aug 29 22:35:13 I couldn't figure out how to disable it. Aug 29 22:35:20 and then the errors "went away" Aug 29 22:35:29 hmm :/ Aug 29 22:35:46 it could definitely be related to that Aug 29 22:36:06 I even logged my flailing. Aug 29 22:36:08 check this out: Aug 29 22:36:15 https://pastebin.com/r1Tzjt4w Aug 29 22:36:40 if you got rid of the fixincludes variant, it built again. Aug 29 22:37:08 but I can't see how my flailing fixed it permantely .. but I'm beginning to wonder :D Aug 29 22:38:04 as usual I'll update on the mailing list if I sort anything more out. Aug 29 22:38:30 zeddii: thanks. I will also reply if I can get anywhere. I need to sleep now but I'll set my builder at this in the morning Aug 29 22:38:46 zeddii: it spent most of today chewing on the multilib issue I mentioned in the email Aug 29 22:38:51 hopefully my breadcrumb might come in handy. Aug 29 22:38:57 I figured that was the one you were least likely to look at Aug 29 22:39:09 yah. that saved me having a real panic attack today. Aug 29 22:39:31 zeddii: that one depended on order of files on the disk Aug 29 22:39:37 RP: are we including sys/socket.h in failing files ? Aug 29 22:39:48 if not then that could be the issue Aug 29 22:40:00 khem: not sure. I did wonder Aug 29 22:40:15 khem: I've not really looked. zeddii wanted to reproduce them first Aug 29 22:40:21 does it happen on qemuppc too ? Aug 29 22:40:26 khem: no Aug 29 22:41:03 khem: but it did happen with qemuppc-lsb Aug 29 22:41:21 whats the difference Aug 29 22:41:22 zeddii: which kernel version were you looking at? Aug 29 22:41:29 khem: kernel version Aug 29 22:41:53 oh so for qemuppc its not bumped to 5.2 ? Aug 29 22:42:10 5.2 Aug 29 22:42:23 and also 5.3 and 4.19 in my builds. Aug 29 22:42:48 hmm. or maybe not 4.19 for ppc. I wonder if that's what it was. Aug 29 22:43:43 Its odd that it happened for qemuppc-lsb (4.19) but not qemuppc (5.2) and yet mpc8315e-rdb (5.2) failed Aug 29 22:44:11 RP: its related to kernel-headers mostly Aug 29 22:44:16 * RP should check the logs to confirm numbers Aug 29 22:44:25 khem: all should be on latest 5.2 kernel headers Aug 29 22:44:36 so you should check linux-libc-headers Aug 29 22:44:48 I wonder if host headers leak through? Aug 29 22:45:04 highly unlikely Aug 29 22:45:55 zeddii: qemuppc which worked is still using 5.0 kernel Aug 29 22:46:15 RP:for kernel headers too ? Aug 29 22:46:19 zeddii: so 5.2 kernel headers + 5.0 kernel is working Aug 29 22:46:24 (for qemuppc) Aug 29 22:47:42 it gets stranger, same versions in the lsb build failed Aug 29 22:52:24 where do I find qemuppc-lsb definition Aug 29 22:52:52 khem: its basically DISTRO="poky-lsb" instead of DISTRO = "poky" Aug 29 22:53:02 khem: now poky-altcfg Aug 29 22:53:09 i c Aug 29 22:53:42 khem: config is always in the stdio log, exactly what goes into auto.conf and local.conf is unmodified from default Aug 29 22:55:28 so it basically use 4.19 kernel for altcfg thats the only relevant change I see Aug 29 22:56:55 zeddii:did it work with musl ? Aug 29 22:57:10 RP:to me it looks more like glibc and linux-libc-headers problem Aug 29 22:58:51 khem: except its not using 4.19 in the logs :/ Aug 29 23:00:03 khem: I'm not convinced its deterministic Aug 29 23:00:52 * RP -> sleep. Will email if I get anywhere tomorrow Aug 29 23:08:34 RP: meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.19.bbappend:LINUX_VERSION_mpc8315e-rdb = "4.19.34" Aug 29 23:08:55 so I guess lsb and mpc8315e-rdb are using same 4.19 kernel Aug 29 23:09:49 well no Aug 29 23:10:56 dont we need meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.2.bbappend as well ? Aug 30 02:20:06 New news from stackoverflow: Where can I find my Linux kernel source directory? **** ENDING LOGGING AT Fri Aug 30 03:00:27 2019