**** BEGIN LOGGING AT Wed Oct 30 02:59:57 2019 Oct 30 07:42:20 good morning Oct 30 07:42:23 What I should do for a build fail on master? Ignore? Report a bug? Write to the mailing-list? Oct 30 08:18:33 New day, new exiting bugs! :D Oct 30 08:19:16 On the menu today, why the !"#ยค%( isn't my systemd bbappend working -_- Oct 30 08:19:40 Pretty much copied this script Oct 30 08:19:41 http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-edison/tree/meta-intel-edison-distro/recipes-core/systemd/systemd_%25.bbappend?h=master Oct 30 08:20:27 Stripped down everything that isn't called journald Oct 30 08:21:18 Aaaaand I get anError: do_rootfs: Function failed: do_rootfs Oct 30 08:21:43 Vomiting like 500 red lines about configuring stuff Oct 30 08:22:03 Can you re-vomit that into a pastebin maybe? Oct 30 08:22:27 If I leave the do_install_append blank, then I get nothing Oct 30 08:22:33 Sure, hang on: Oct 30 08:23:20 and also maybe paste your stripped down bbappend Oct 30 08:24:35 The bbappend (systemd_%.bbappend) Oct 30 08:24:36 https://pastebin.com/vSuRSxY5 Oct 30 08:25:20 And yes, the journald.conf exists Oct 30 08:25:53 yeah otherwise it would complain during the building of systemd, not during do_rootfs Oct 30 08:26:51 If it's during do_rootfs I suspect that it might be that two packages tries to install the same file, but let's see when it's in pastebin Oct 30 08:29:06 https://pastebin.com/R4U4zYtg <-- First line is the build command and everything that comes after that is the build log Oct 30 08:29:32 Apparently 2000 lines of vomit, sorry :P Oct 30 08:29:44 "Collected errors:" Oct 30 08:29:44 * check_data_file_clashes: Package systemd wants to install file /mnt/extra/yocto/spark/build/tmp-glibc/work/sitara-oe-linux-gnueabi/spark-dev-image/1.0-r0/rootfs/etc/systemd/journald.conf Oct 30 08:29:48 But that file is already provided by package * systemd-conf Oct 30 08:30:28 Seems like there's a /etc/systemd/journald.conf in both systemd and systemd-conf Oct 30 08:30:36 Yeah, I see that one... So if I rename my append to systemd-conf it should work then Oct 30 08:31:00 First find out what recipe is providing systemd-conf Oct 30 08:31:30 oh, seems like it's called systemd-conf Oct 30 08:32:07 So yes, renaming the bbappend should do the trick Oct 30 08:33:10 Ah, easy found but when you get 2k lines of log files it Oct 30 08:33:42 it's a bit hard to work through them -_-;; Sorry for the inconvenience Oct 30 08:34:04 No worries, glad I could help Oct 30 08:42:19 Yeah, thanks for the help, it works better now :) Oct 30 09:01:12 Thanks wertigon I have faced the same issue last week and did not investigate further because I had other priorities. Oct 30 09:04:27 rreignier: just managed to poke the person who knows and the answer is: yes, there is quite some bit of stuff hardcoded, so at least at the moment there is no out of the box way to install it to anywhere else than /boot Oct 30 09:07:53 rreignier: he asks that you raise a ticket in our bugzilla, so he can get the ticket assigned to avoid it being forgotten. Oct 30 09:08:11 LetoThe2nd: Oh, thank you. I am looking a bit harder in the 2 /boot and 2 rootfs case using UEFI bootorder. So I can keep the kernel in /boot. The issue for now is to create UEFI boot entries from Yocto. It seems like an operation that should be done on the real hardware because it changes the efivars. Oct 30 09:08:50 rreignier: maybe, but thats completely out of my area of expertise then. Oct 30 09:09:03 And the wic tool does not support two partitions with "--source bootimg-efi" because it complains about boot.img already exists while processing the second partition. Oct 30 09:09:56 rreignier: if you have a valid usecase, please drop it onto the mailing list asking for suggestions on how to approach it Oct 30 09:10:35 LetoThe2nd: Ok. I remember reading something in the Yocto manual that if the action fail on the host system, it will be done on the first boot on the target. Oct 30 09:11:05 rreignier: i'm out given the topic, sorry. just giving generic advice on how one could procedd. Oct 30 09:11:20 LetoThe2nd: Ok, thanks for the tip. I am working on a minimal system available on Github to show my issue. Oct 30 09:11:49 It's ok. I am new to this community so any advice is welcomed! Oct 30 09:26:09 something that's puzzling me for some time with linux-yocto: setting KBUILD_DEFCONFIG = "x86_64_defconfig" does not have the same behaviour at all that "make x86_64_defconfig" has - I believe that's not wanted behaviour, right ? Oct 30 09:27:05 I'm ending out crafting a "sync.cfg" for each kernel update to make sure I do get the x86_64_defconfig content, that's a bit of a PITA :) Oct 30 09:51:13 Hummm Oct 30 09:51:19 So, back to the SDK Oct 30 09:51:44 See a line "ASSUME_PROVIDED += "nativesdk-perl"" Oct 30 09:51:50 Wonder if that solves my problem? Oct 30 09:52:58 Or rather, that line causes my problem and might solve it :P Oct 30 09:53:10 *removing might solve it Oct 30 10:05:45 I SOLVED THE FRICKEN SDK BUILD PROBLEM! :o Oct 30 10:06:08 * wertigon runs a couple of victory laps around his desk Oct 30 10:06:40 rburton: hi Oct 30 10:06:58 rburton: you mentioned this KERNEL_PACKAGE_NAME a couple of days ago Oct 30 10:07:14 weltling: who broke what? Oct 30 10:07:38 wertigon: who broke what? Oct 30 10:07:58 rburton: hopefully this is available in morty, in our new attempt. But we also need to support daisy as well... what did we have to do before KERNEL_PACKAGE_NAME was introduced? Oct 30 10:08:29 I would like to have the package name as kernel, kernel-modules, etc. Oct 30 10:08:31 without the version in it. Oct 30 10:08:45 since I do not specify that explicitly in my recipe, I believe inherit kernel is doing that for me Oct 30 10:09:01 DAISY Oct 30 10:09:03 jesus Oct 30 10:09:14 Oct 30 10:09:19 well, C or even Python is much older than daisyu Oct 30 10:09:22 daisy* Oct 30 10:09:30 C doesn't have thounsands of security issues Oct 30 10:09:44 rburton: Apparently someone had written in our distro conf file: Oct 30 10:10:02 wertigon: which is fine and in fact what i endorse. curious what they broke Oct 30 10:10:06 ASSUME_PROVIDED += "nativesdk-perl" Oct 30 10:10:09 haha Oct 30 10:10:35 i wonder what that was added for Oct 30 10:10:50 because the dummy-perl thing is exactly to solve that problem but in a way that actually works :) Oct 30 10:11:02 Yeah, a comment says "Do not package own copy of perl into devkit, rely on host one" Oct 30 10:11:52 This package does have some legacy from the thud-2 days Oct 30 10:11:55 well glad you found the problem Oct 30 10:12:07 right, thats most likely the cause Oct 30 10:12:40 Yeah, I think this is a hack from thud-2 and then it carried over, just need to doublecheck with developer first Oct 30 10:13:19 I can build meta-toolchain now, and perhaps also I can populate_sdk too Oct 30 10:13:38 Let's see in a few minutes when build completes :) Oct 30 10:18:44 lpapp: for releases that old i'm not sure. why does it matter what filename the package has? Oct 30 10:27:03 rburton: because we are updating the kernel and we prefer to have one kernel installed Oct 30 10:27:19 rburton: rather than accumulating. opkg will not replace, but extend if the version is in the package name Oct 30 10:27:39 rburton: opkg will not remove 3.2.1-r21 when installing 3.2.1-r22 if the version is in the package name Oct 30 10:27:48 you'd have to read kernel.bbclass, specifically the bits where it sets PKG Oct 30 10:28:07 ok, thanks. Oct 30 10:30:56 rburton: also, I have this, PR = "r22" Oct 30 10:30:56 LINUX_VERSION_EXTENSION ?= "-polatis-${PR}" Oct 30 10:31:17 rburton: but it does not seem to make it into the ipk name, why? Oct 30 10:31:37 the CONFIG_LOCALVERSION in the defconfig does, but I thought LINUX_VERSION_EXTENSION was supposed to achieve the same in a nicer way? Oct 30 10:31:51 ernel-module-zl10039-4.19.73-intel-pk-standard_4.19.73+git0+a7cb57afb9_ca05e9cd64-r0_corei7-64-intel-common.ipk Oct 30 10:31:54 PR is in my packages Oct 30 10:32:10 * rburton doesn't know much about kernel packaging Oct 30 10:32:34 yeah, and this variable does appear in the daisy kernel development manual Oct 30 10:32:37 so should just work Oct 30 10:32:43 I am not sure why it is working for you, but not for me. Oct 30 10:32:53 well i'm on zeus for a start Oct 30 10:33:00 you'll have to chase the variables yourself Oct 30 10:33:44 bitbake -e linux-polatis | grep ^LINUX_VERSION_EXTENSION Oct 30 10:33:44 LINUX_VERSION_EXTENSION="-polatis-r22" Oct 30 10:33:50 so, the resolution happened ok at least Oct 30 10:33:55 rburton: SDK built, thank you for the rubberducking :) Oct 30 10:34:17 wertigon: awesome. maybe skim the rest of that config to see if there's anything odd :) Oct 30 10:34:33 Now I just need to figure out how to transfer this SDK to the devs sitting on Windows 10... Oct 30 10:35:05 wertigon: built a windows sdk with meta-mingw? Oct 30 10:35:43 rburton: needs to inherit kernel-yocto, apparently, Oct 30 10:35:49 unless I write my own .bbclass :D Oct 30 10:43:02 rburton: hmm, even in zeus, it is only part of the yocto bbclass Oct 30 10:43:12 rburton: that is probably not ideal, but also not documented Oct 30 10:43:30 the kernel docs read as if it was available by inheriting the kernel and that would probably also make sense Oct 30 10:43:44 why not move that one line? _EXTENSION[doc] = "A string extension compiled into the version string of the Linux kernel built with the OpenEmbedded build system. You define this variable in the kernel recipe." Oct 30 10:43:48 ./meta/classes/kernel-yocto.bbclass:339: echo "CONFIG_LOCALVERSION="\"${LINUX_VERSION_EXTENSION}\" >> ${B}/.config Oct 30 10:46:43 rburton: would it be acceptable to move this down to kernel.bbclass? Cannot think of a reason how this support is yocto kernel specific Oct 30 10:55:15 my kernel does not even build when I inherit linux-yocto, so I would rather stay away from it Oct 30 13:51:31 is it possible to limit/increase the sstate size? Oct 30 14:17:40 leitao: nope, what would be the usecase? Oct 30 14:18:52 leitao: we have warnings if you run out of space, but sstate is not like something to discuss on a package by package basis. if you need to build something, then you need the space. so a limit would just break the build if in doubt. Oct 30 14:44:16 rburton: 1c2ea784f43dba4fd897eaf730933fa916b85c6e breaks master for ppc on my builder. Oct 30 14:45:44 rburton: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass?h=daisy#n356 Oct 30 14:45:54 I should override PKG_kernel-base and PKG_kernel-image? Oct 30 14:46:08 in order to drop the "${@legitimize_package_name('${KERNEL_VERSION}')}" parts? Oct 30 14:47:57 hello a class that I inherit disables a task using noexec. How do I override the noexec in my class to re enable the task? Oct 30 14:48:30 I tried noexec=0 in my class - but that doesnt seem to take affect. Oct 30 14:53:47 LetoThe2nd I have a big disk, and I want to make sure that yocto can use as much as it needs Oct 30 14:57:10 I wonder if it's a bad idea to try and get Visual Studio to play nice with WSL and a Yocto SDK Oct 30 15:06:54 rburton: after inheriting kernel? Oct 30 15:14:26 Chaser, should work! but you need to have your inherit come later than the one of the disabling class Oct 30 15:14:43 attribute assignments cannot use OVERRIDE, i believe? so that should not be the cause Oct 30 15:19:02 leitao: it will use as much as it needs, since there's no limitation Oct 30 15:20:05 erbo ok, is it configured somehow or just the default behaviour? Oct 30 15:25:13 Hello. Some can explain to me how to configure yocto (gcc actually) not to strip any binary that it compiles in the image that it builds? Oct 30 15:26:20 naknick: why would you not use a debug build for that? Oct 30 15:27:35 naknick: https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-INHIBIT_PACKAGE_STRIP ? Oct 30 15:30:12 naknick: you don't really need to prevent stripping. we don't destroy the debug data, we split it out into separate files, which can be easily installed into the image as needed Oct 30 15:30:25 eitehr as individual packages or by adding dbg-pkgs to image features Oct 30 15:30:41 but yes, you can if you really want to Oct 30 15:52:31 lpapp and kergoth - thank you both. If I really want to compile with no stripping - how should I do that? Oct 30 15:53:10 ah lpapp sent it already. OK. I thought he sent something about debug Oct 30 15:53:20 thanks Oct 30 15:53:25 he already told you how to disable stripping. changing compilation is different. we always compile with debug (-g), but we also enable optimization. there's a separate variable to control that, if the optimization causes debugging problems at all Oct 30 15:54:40 And I just need to add that line to local.conf file? Oct 30 15:54:51 anyone seeing: "patchelf-uninative: ../../patchelf-0.10/src/patchelf.cc:382: void checkPointer(const FileContents&, void*, unsigned int): Assertion `q >= contents->data() && q + size <= contents->data() + contents->size()' failed." on prebuilt native binaries when uninative is enabled? Oct 30 16:01:49 * mcfrisk is off to Lyon Oct 30 16:04:47 If you wrote a message to me - I missed it Oct 30 16:22:59 looking at https://github.com/crops/poky-container - is this supposed to work with every version of poky? i kind of expected to see a tag for every poky release or something like that Oct 30 16:43:25 New news from stackoverflow: OpenBMC with Raspberry Pi (2 or 3) and build bmcweb? Oct 30 16:57:55 naknick: which line? Oct 30 17:37:16 HI, i'm trying to boot with QEMU a core-image-minimal using the congatec-tca5-64 machine configuration (meta-congatec) (which is based on intel-corei7-64 machine configuration from meta-intel), and QEMU hangs out printing "Booting the kernel." and nothing else. Did somebody have the same issues ? Oct 30 17:38:56 runqemu works for a normal intel-corei7-65 machine so maybe ask contatec directly? Oct 30 17:41:49 i'm not able to build core-image-minimal with intel-corei7-64 , they asks for cgos recipes (provided by meta-congatec). But the kernel has the same TUNE_ parameters (tune, arch, cpu) as intel-corei7-64. Oct 30 20:58:54 leitao: then no need to do anything. bitbake will take all the space it needs. Oct 30 21:21:46 Hello Oct 30 21:22:00 Is this the best place to ask questions on bitbake recipe design? Oct 30 21:22:52 penguin359: you can certainly ask. Oct 30 21:23:15 penguin359: if its complicated, then the mailing list is probably a better choice though Oct 30 21:23:32 I have a simple recipe that basically is just an unpack and then install. It has nothing to compile. Oct 30 21:23:42 and? Oct 30 21:24:17 It was working before without me defining a do_compile() step, but now it's trying to run oe_runmake and failing to find a Makefile. Oct 30 21:24:55 penguin359: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#packaging-externally-produced-binaries Oct 30 21:24:57 I added do_compile() { :; } to the bb file, but bitbake my_package is still trying to run oe_runmake Oct 30 21:25:06 penguin359: exactly that, see the noexec secton Oct 30 21:25:37 OK, I'll try that now. Oct 30 21:26:48 It's still doing oe_runmake. It's like it's using a cached copy of my recipe. Oct 30 21:28:52 penguin359: can you show the recipe on a pastebin? Oct 30 21:29:40 Well, introducing a syntax error breaks it. Oct 30 21:29:53 Let me sanatize it for public consumption. Oct 30 21:34:35 https://pastebin.com/KnaFqwQC Oct 30 21:35:14 It just grabs agent from package-${PV}.zip and has package.service in the files/ folder for the recipe. Oct 30 21:37:26 penguin359: does that zip happen to contain a makefile as pointed out by the docs? Oct 30 21:37:42 penguin359: because you didn't noexec the do_configuration stage Oct 30 21:38:52 No Oct 30 21:39:27 The error is coming from do_compile so I didn't worry about configure since that appeared to have been skipped automatically. Oct 30 21:39:41 This recipe was working with earlier releases of Thud. Oct 30 21:39:50 The zip is unchanged. Oct 30 21:40:57 penguin359: then i'd conclude, either bisect or mailing list. at least i am not aware of any breaking change in that context, so it *might* be a regression Oct 30 21:41:28 From the doc you sent me: "It is usually sufficient to just not define these tasks in the recipe, because the default implementations do nothing unless a Makefile is found in ${S}." Oct 30 21:41:38 penguin359: thats why i asked :) Oct 30 21:42:33 So it appears it's somehow triggering the Makefile behavior. My bitbake layer has not changed recently, but I'll check the build outputs to make sure. Oct 30 21:43:33 penguin359: given the information so far that is the interpretation, yes Oct 30 21:43:53 Either way, how come my attempts to define a custom do_compile() doesn't stop the oe_runmake it does? Oct 30 21:44:22 no idea, sorry Oct 30 21:49:29 Thanks for the feedback! Oct 30 21:49:54 yw, have fun and good luck Oct 30 23:07:44 It's occurred to me that it's also failing to pick up the correct version from the recipe file. Oct 30 23:08:29 One package that's successful gets packages as 1.0-r0 instead of 2.43.1-r0 and this failing package is showing as abc-r0 Oct 30 23:08:52 It's not using the version from the bb filename as before. Oct 31 00:22:11 JPEW: i did a thing Oct 31 00:22:12 WARNING: QA Issue: opkg-utils-doc contains non-reproducible man page /usr/share/man/man1/opkg-build.1 [podman] Oct 31 00:22:24 running a world test now to see what the damage is Oct 31 02:45:00 New news from stackoverflow: IR remote control using LIRC. (NEC) **** ENDING LOGGING AT Thu Oct 31 02:59:58 2019