**** BEGIN LOGGING AT Thu Apr 05 03:00:05 2018 Apr 05 05:30:19 subscription is required for ml Apr 05 06:47:18 hello guys ! I have a question. not strictly related to yocto this time... I have a bounch of files in a folder and I vant to tar/zip them in order to fill a partition using for example cat myarchive.xx | dd bs=4M of =/dev/sdb1. Is it sufficient to tar/zip the archive the standard way ? Apr 05 06:52:03 New news from stackoverflow: Difference between class-target and class-native in yocto recipe Apr 05 06:53:44 JPEW, RP: apparently glibc did not merge the patch to depecrate libcrypt, so do I have to patch glibc with the commit to deprecate it and add libxcrypt? Apr 05 06:54:13 because I guess it is an issue to try to apply this kind of change before glibc merged it Apr 05 06:55:09 (the proposal patch is here: https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html) Apr 05 07:22:13 Renault: we might have to apply it only for nativesdk-glibc Apr 05 07:23:47 RP: sure that it applies "there"? Apr 05 07:28:24 LetoThe2nd: its where uninative comes from? Apr 05 07:28:54 Renault: I'm a little worried that fedora have moved ahead with this before glibc did :/ Apr 05 07:29:24 RP: that surprised me too Apr 05 07:31:09 * LetoThe2nd underlines the '"'s for RP Apr 05 07:33:02 LetoThe2nd: clearly I need caffeine as I don't understand :) Apr 05 07:37:12 RP: http://lists.openembedded.org/pipermail/openembedded-architecture/2018-April/000714.html Apr 05 07:39:08 LetoThe2nd: ah, I didn't quite get a post release connection :) Apr 05 07:40:42 :-) Apr 05 08:24:25 RP: how is fedora's deprecation affecting builds ? Apr 05 08:34:24 Hi Guys, I want to create a grubenv with grubefi Apr 05 08:34:33 By default it doesn't create that Apr 05 08:34:56 So i edited grub-efi_2.02.bb file and added the following line Apr 05 08:35:09 do_deploy_append_class-target() { grub-editenv grubenv create } Apr 05 08:35:30 While running bitbake it is throwing error : "grub-editenv: not found" Apr 05 08:35:45 I did a search in the file system : locate grub-editenv Apr 05 08:37:13 Hi ! anyone who have experience with failed do_package task? I build libreoffice package on my project but this failed because of many library he couldn't find. I view in the log.do_package file (here: https://uploadfiles.io/dwulu) that it "runstrip" the same library. Apr 05 08:48:41 khem: its broken uninative as we're no longer compatible :( Apr 05 08:48:45 khem: missing symbols Apr 05 08:49:08 khem: new symbols added in libxcytpro which things like to on fedora Apr 05 08:49:25 khem: Can you find out what glibc's plans are for that patch? Apr 05 08:52:26 New news from stackoverflow: grubenv in yocto efi mode throws error grub-editenv not found Apr 05 08:53:05 "new symbols added in libxcrypto which things link to on fedora" Apr 05 08:53:06 RP: uninative build works, I'm trying to build core-image-minimal with it Apr 05 08:53:11 clearly going to be one of those days :/ Apr 05 08:53:35 Renault: cool. The real test will also be using that uninative on a non fedora28 system Apr 05 08:55:30 of course, I can't test that part today, I can eventually send you the file + patch Apr 05 08:58:03 Renault: if you can share the uninative tarball though, I suspect someone here can! Apr 05 08:58:21 that should be possible today yes Apr 05 09:00:03 RP: this will get in 2.28 Apr 05 09:00:24 deprecations are usually implemented after 2 releases Apr 05 09:00:34 after they are declared Apr 05 09:07:24 khem: are you sure that this one will be applied? Because there is no trace to this patch inside git repository, it could be applied without disable this part of code by default Apr 05 09:13:45 khem: this is a case we really could do with knowing for sure... Apr 05 09:40:05 RP: I have to include a Perl fix too (that is available upstream for Perl 5.26.1 but Poky master still use Perl 5.24), I have to separate commits? Apr 05 09:59:13 Renault: separate commits are best, yes Apr 05 10:52:51 New news from stackoverflow: Yocto error: Building libreoffice package fails in do_package task Apr 05 11:01:14 hi. do you have any idea why there is no lo interface available ? ifconfig doesn't show it . but it is present in /etc/network/interfaces: auto lo iface lo inet loopback Apr 05 11:03:39 ggtk: what board? what kernel? specific configuration? Apr 05 11:03:52 ggtk: i mean /etc/network/interfaces is rather debian specifc Apr 05 11:06:11 it something based on sama5d4, kernel 4.14.14 Apr 05 11:06:36 what do I have to check in the kernel ? maybe something is missing there Apr 05 11:07:26 ggtk: well, what layers are you using? what release... you are basically providing no details so far. Apr 05 11:11:31 sorry for that, didn't know how much information to provide as it looked for me it's something general, not board specific. layers: meta-atmel,meta-openembedded/meta-oe ,meta-openembedded/meta-networking ,meta-openembedded/meta-python ,meta-openembedded/meta-webserver + my own layer which among others provides the kernel recipe + kernel configuration. I'm on the rocko branch Apr 05 11:13:49 image is based on core-image-minimal, it contains the ifconfig pkgs, not the busybox Apr 05 11:22:21 also ifconfig -a shows the lo interface but with no inet addr set Apr 05 11:23:50 ggtk: my interpretation is that somebody/something assumes that you use debian-style configuration, which is not true obviously Apr 05 11:24:42 so either the process/script bringing the interfaces up is not there, or not being started. Apr 05 11:30:04 the other 2 interfaces, from /etc/network/interfaces, are configured ok by ifupdown, even bridge is handled ok Apr 05 11:31:23 ok, then i personally have no idea. Apr 05 11:33:59 ok, I appreciate your input ! Apr 05 11:56:38 is yocto recipe allowed to have unicode characters? getting unicode errors from old recipes when porting to new yocto version Apr 05 12:38:31 mcfrisk: the move to python3 probably means there were changes Apr 05 12:55:22 RP: yes, figured out that the file had wrong 8859 encoding which breaks with python3, pure utf8 was fine Apr 05 12:55:42 where to find ruby.bbclass nowadays? Apr 05 12:59:25 RP, JPEW: build succeed Apr 05 12:59:38 you can download the uninative built: https://blog.fedora-fr.org/public/renault/Yocto/x86_64-nativesdk-libc.tar.bz2 Apr 05 12:59:42 hello guys, the watchdog recipe also create the watchdog-keepalive package. watchdog-keepalive ships /usr/sbin/wd_keepalive. I need that file to be included in my rootfs. So in one of my recipe I have added DEPNDS= "watchdog-keepalive". by the way bitbaking this recipe causes this error: Apr 05 12:59:44 Nothing PROVIDES 'watchdog-keepalive' (but /home/worker/iagocto/build/../poky/meta/recipes-bsp/u-boot/u-boot_2017.09.bb DEPENDS on or otherwise requires it). Close matches: Apr 05 12:59:44 watchdog RPROVIDES watchdog-keepalive Apr 05 13:00:02 and patches: https://blog.fedora-fr.org/public/renault/Yocto/0001-Split-glibc-and-libcrypt.patch and https://blog.fedora-fr.org/public/renault/Yocto/0002-Add-Perl-s-patch-from-upstream-to-be-compiled-along-.patch Apr 05 13:00:29 by the waya using only DEPENDS="watchdog" doesn't add wd_keepalived Apr 05 13:00:31 I made test on master branch of Poky with core-image-minimal target Apr 05 13:10:56 RP, JPEW: do not hesitate to send me a feeback by email, use the commit's email in that case Apr 05 13:11:15 I don't have the time to make a test before this week-end on F27 Apr 05 13:16:04 Renault: I'll give the uninative a spin on FC27. Thanks! Apr 05 13:17:11 Renault: thanks, I've just added your tarball to my local test build, lets see what happens... Apr 05 13:18:14 but so, it is probably no too important but libcrypt in my uninative is under /usr/lib and not /lib, I used $libdir instead of $basic_libdir in the recipe... Apr 05 13:54:48 RP sent pull request for morty-next Apr 05 13:59:15 Renault: FWIW this seems to be working well on my Ubuntu test builds Apr 05 14:00:17 RP: thanks :) Apr 05 14:02:16 * armpit dang it Apr 05 14:03:06 armpit: the mingw failure? don't worry, I know how to fix tat Apr 05 14:04:57 RP: come again. you use "mingw" and "fix" in one sentence? rly? Apr 05 14:05:01 Apr 05 14:05:26 LetoThe2nd: two different sentences Apr 05 14:06:14 * RP wishes he could "fix" mingw properly with rm Apr 05 14:06:32 * armpit was caught by the wiki / AB race condition again Apr 05 14:06:48 armpit: which wiki/AB race? :/ Apr 05 14:08:11 armpit: I assume I should bin my morty-next and replace with yours? Apr 05 14:08:12 look at wiki, clean, look at ab, clean.. I need to wait a bit longer Apr 05 14:09:30 RP, yes, I moved your "fix" patches into their correct patches Apr 05 14:10:07 armpit: thanks, just checking Apr 05 14:10:58 armpit: and nicely done fixing the sdk bits, thanks! Apr 05 14:11:02 RP: what is the next step? Send patches to the mailing list? Apr 05 14:11:16 np, now what to do with all my free time ; ) Apr 05 14:11:27 Renault: yes. Your patches need some tweaks like missing Upstream-Status header adding Apr 05 14:12:01 I suppose I have to use $basic_libdir too Apr 05 14:12:21 Renault: you mean base_libdir? Apr 05 14:12:29 Renault: I haven't looked into that bit Apr 05 14:12:49 libcrypt is installed in /usr/lib instead of /lib directory Apr 05 14:12:55 libxcrypt* Apr 05 14:13:26 Renault: core-image-minimal finished successfully on F27 Apr 05 14:13:40 o/ Apr 05 14:14:00 Renault: does that cause any problem though? Apr 05 14:15:22 no, but that is not really consistent Apr 05 14:15:22 armpit: morty merged and mingw fix pushed too Apr 05 14:15:31 Renault: consistent with what? Apr 05 14:15:45 other lib* files provided by glibc Apr 05 14:16:45 Renault: I'm not sure it matters, we probably need to follow the conventions used for the new lib going forward? Apr 05 14:16:58 armpit: hmm, just saw your "ignore this" email :/ Apr 05 14:17:07 ok Apr 05 14:17:26 Renault: it depends if its causing a real world issue Apr 05 14:19:48 RP, what did you push? the fix ups are missing Apr 05 14:20:11 armpit: your branch? Apr 05 14:20:33 * armpit hehe looking at pyro Apr 05 14:21:06 armpit: You're trying to give me a heart attack? :) Apr 05 14:24:09 armpit: I just pulled in that sanity backport for morty since it should be safe Apr 05 14:27:15 k, but I am no ( sane ) Apr 05 14:28:31 Renault: hmm, do_rootfs failed with locale problems Apr 05 14:28:43 which target? Apr 05 14:28:54 Renault: core-image-sato Apr 05 14:29:04 I will make a try Apr 05 14:29:27 Renault: this was on my ubuntu machine, not f28 so there could be a variety of reasons for it Apr 05 14:29:37 ERROR: core-image-sato-1.0-r0 do_rootfs: [log_check] core-image-sato: found 4 error messages in the logfile: Apr 05 14:29:37 [log_check] Failed to set locale, defaulting to C Apr 05 14:30:04 yes, but we have to investigate :) Apr 05 14:30:12 indded Apr 05 14:30:18 stephano, you are late Apr 05 14:31:50 so I started a build to check this on F28 Apr 05 14:31:55 with my change Apr 05 14:38:43 armpit: I was late for a very important reason.... coffee :) Apr 05 15:01:42 moto-tim1: with this lscpu "bug" I just realized how many similar misconceptions and wrong assumptions I'm gating and filtering internally from our devs and users... :) Apr 05 15:14:51 denix: indeed :) Apr 05 15:28:38 RP, looks like I forgot distcc in pyro Apr 05 15:29:54 RP, its in pyro-next Apr 05 15:40:21 Hi all, it's probably not the right channel but i wiil try :) I'm trying to add Avnet Minized board support in u-boot-xlnx but i'm stuck on : sdhci_transfer_data: Error detected in status(0x208000)! Any idea ? everything seems ok after this error ->sdhci@e0101000: 0 (eMMC) so it's maybe just a warning ... Apr 05 16:05:18 RP, JPEW: so core-image-sato succeed on my side Apr 05 16:05:43 (with my change + F28 of course) Apr 05 16:06:03 I haven't seen anything on my end yet, but I haven't tried core-image-sato. I'll start one soon Apr 05 16:34:25 armpit: I sorted pyro, I'd forgotten to run some scripts. was there in oe-core but not poky Apr 05 16:58:36 core-image-sato completed successfully with Renault's uninative on Fedora 27 Apr 05 16:59:51 JPEW: good data point thanks. I wonder why my builds are broken :( Apr 05 17:00:04 I really could do without another failure to debug Apr 05 17:00:20 RP: Did you bring in the patches also or just the uninative? Apr 05 17:01:16 Also, what version of Ubuntu do you run? Apr 05 17:15:11 Hello. Apr 05 17:20:29 I'm building pooky for a rpi3, using meta-raspberrypi .I wish to disabled bluetooth but when I add dtoverlay=pi3-disable-bt to /boot/config.txt , the rpi3 boot on a rainbow screen.Can somebody help please ? Apr 05 18:16:48 pooky - that's new... :) Apr 05 19:00:14 I'm getting these systemd errors when I try to populate my esdk. https://pastebin.com/1nXsMYvW Any ideas? Apr 05 19:00:21 how do i add stuff to the device tree in my build? Apr 05 19:05:41 i'm gonna try this "meta-mentor" thing Apr 05 20:11:40 JPEW: just uninative but that should be all that is needed? or would I need the perl one? Apr 05 20:13:20 RP: I don't think so, I was just curious so I could try to reproduce Apr 05 20:18:29 Ok, I just build core-image-sato with the new uninative in a Ubuntu 16.04 container (FC27 host), and it was successful Apr 05 20:18:48 JPEW: I ran into the issue on a 1604 system :/ Apr 05 20:19:05 JPEW: sorry, 1710 Apr 05 20:19:19 Ok, I can spin up a container quick for that :) Apr 05 20:19:34 I mean, more testing certainly doesn't hurt ;) Apr 05 20:31:15 JPEW: which package manager are you using? Apr 05 20:31:22 * RP is using rpm in this case Apr 05 20:32:31 I am also using rpm Apr 05 20:34:35 JPEW: was worth checking :) Apr 05 20:36:52 JPEW: just for reference I did this in an existing builddir, it was not a from scratch build. I've looked at the contents of the sysroot-uninative dir and it worries me a bit. Trying a cleaner directory... Apr 05 20:37:17 is there a way to find out what .dts files are going to be used in the build? Apr 05 20:37:21 and/or "dtsi" Apr 05 20:37:23 RP: Ok. I've only done clean builds Apr 05 20:38:10 Thank you LXC.... I have a brand new Ubuntu 17.10 container running bitbake in under 15 minutes Apr 05 20:38:34 JPEW: something is very wrong with my setup as the uninative files look very very old :/ Apr 05 20:40:19 nevermind... i figured it out: bitbake -e | grep ^DISTRO_FEATURES Apr 05 20:40:39 errr sorry KERNEL_DEVICETREE Apr 05 20:40:48 Does anyone know if it's possible to make bitbake "keep going" if it gets a failure? Apr 05 20:41:03 As in, build as much as possible despite the failure Apr 05 20:41:41 brianm_: see bitbake --help Apr 05 20:41:54 specifically the -k argument, which does exactly that. same argument as in gnu make Apr 05 20:42:32 kergoth: great, thanks Apr 05 20:42:35 TIL about make -k Apr 05 20:42:37 JPEW: I think this is all my fault, I'm testing something else entirely. Still not sure how :/ Apr 05 20:43:59 RP: Ok, I'll let my sato build finish on 17.10 anyway. So far I've had no issues build core-image-sato on 16.04 or FC27, so it's looking pretty good. Do you think there are better build targets to try? Apr 05 20:44:23 JPEW: other key thing is -c populate_sdk_ext and populate_sdk Apr 05 20:44:33 K, I'll try those too Apr 05 20:47:26 JPEW: do_rootfs worked so it was user error. I'll try another build but I think this was down to misconfig on my part, sorry Apr 05 20:47:44 too many things at once :( Apr 05 20:48:21 RP: no problem Apr 05 20:49:42 JPEW: thanks for the help btw, it is very useful Apr 05 20:55:01 Any idea how to debug/address this? ERROR: iproute2-4.9.0-r0 do_fetch: Taskhash mismatch fadfed177998cd79e3a2936862e490de versus 14741751454fd2a8f5114c7c199d4290 for /home/paul/src/bronte2/project-spec/meta-janteq-zynq/recipes/iproute2/iproute2_4.9.0.bb.do_fetch Apr 05 20:57:43 pstone1: I have to wonder why the meta-janteq-zynq needs its own iproute2 recipe and what that recipe is doing... Apr 05 21:02:53 This is using petalinux. I think we had to include that recipe in order to obtain a specific version of iproute2, which was not the version provided by petalinux. Apr 05 21:04:37 I tried adding the following to the layer, based on information I found on the web, but it didn't help: DISTRO_VERSION[vardepsexclude] = "DATETIME" Apr 05 21:10:45 pstone1: do you have a link to the recipe you've added and some details about what exactly you're building it against. I suspect some kind of mistmatch Apr 05 21:29:41 Here is the recipe, minus patches. I can add the patches if needed. https://pastebin.com/AyBcGeja https://pastebin.com/VJX6a9ZS Apr 05 21:33:30 Using petalinux-v2017.3, based on "Morty" version of Yocto Apr 05 21:36:37 pstone1: nothing about that recipe looks like it would cause a fetch checksum issue. Which makes me wonder if its something else in your metadata that is doing it... Apr 05 21:36:53 pstone1: machine or distro config Apr 05 21:42:31 ok, i need the "pwm-backlight" driver in my build. the code already exists in my freescale layers. how do i tell it do put that stuff in the build? Apr 05 21:44:11 It's not just fetch which fails with the taskhash mismatch. That's the first failure, which is followed by the following failures: unpack, patch, populate_lic, configure, compile, install, package, packagedata, populate_sysroot, package_qa, and package_write_rpm. Maybe, the other failures are just due to the fetch failure. Apr 05 21:46:31 pstone1: is it the only recipe? Apr 05 21:47:50 JPEW: new build successful :) Apr 05 21:48:16 Yes, iproute2 is the only recipe this occurs with. Apr 05 21:50:19 pstone1: I don't understand it, its very odd Apr 05 21:53:26 is there a way to get a list of available kernel features? Apr 05 21:53:54 pstone1: and a quick test here against master doesn't show a mismatched hash Apr 05 21:54:27 bitbake-dumpsig output is here: https://pastebin.com/brRyeQbP I noticed that SRCREV is INVALID. I don't know if that could cause an issue. Apr 05 21:56:27 pstone1: hmm, why is there a dependency on SRCREV I wonder Apr 05 21:57:11 do_fetch[vardeps] += "SRCREV" Apr 05 21:57:26 pstone1: it would only be an issue if the value changed... Apr 05 21:58:37 how can i get toaster to fetch the layer index from openembedded? it's supposed to do it on start-up but i guess it doesn't Apr 05 21:59:11 pstone1: I just wondered about http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ff6d458f9ad4e2aed24997aea15ec930b0915c26 ? Apr 05 21:59:17 pstone1: does morty have that change? Apr 05 22:02:01 Hmmm... libgcc is failing during do_configure for me: ld: cannot find crtbegin.o: no such file or directory Apr 05 22:03:52 Ah, not uninative related.... looks like an Icecream problem. Have to look into it tomorrow Apr 05 22:13:46 RP, that change is in my version of petalinux/yocto (Morty). Apr 05 22:24:02 I wonder if the problem might be that the iproute2 recipe has the same name as an existing recipe, and maybe that is causing some interference. It looks like the base recipe has a bbappend file which is adding a dependency on a patch. The bbappend is simply the following: Apr 05 22:24:02 FILESEXTRAPATHS_prepend := "${THISDIR}/files:" Apr 05 22:24:02 SRC_URI += "file://0001-fix-UNIT16_MAX-failure.patch" Apr 05 22:33:57 is there a way to get bitbake to tell you what kernel it'll be using in your build? Apr 05 22:35:33 pstone1: there is a recipe with exactly the same name? Apr 05 22:40:10 There are two recipes that start with iproute2 and are followed by different version information. Additionally, under the petalinux yocto installation, there is a bbappend file, named iproute2_%.bbappend, which I suspect is being applied against our iproute2 recipe, although that may not have been the intention. I think if we put our own iproute2 recipe in, then we probably wanted it to be standalone, because we wanted that specific versi Apr 05 22:40:10 on. I will double check and maybe try renaming our recipe to see if it makes a difference. Apr 05 22:41:32 Under petalinux-v2017.3, there is iproute2_4.7.0.bb. Under our source code tree, there is iproute2_4.9.0.bb Apr 05 23:36:50 how do i tell yocto to redownload one of the repositories? i have a corrupt file Apr 05 23:38:09 AbleBacon: delete the files from DL_DIR ? Apr 05 23:38:18 but only a single file is corrupt Apr 05 23:38:27 AbleBacon: so delete the single file? Apr 05 23:38:36 tried, that, now the file is not found Apr 05 23:38:56 AbleBacon: is there an similarly named related file? Apr 05 23:39:04 i don't think so Apr 05 23:39:05 a .done or similar? Apr 05 23:40:15 i don't see anything like that Apr 05 23:40:58 AbleBacon: what was the file? Apr 05 23:41:22 lassimp Apr 05 23:42:11 AbleBacon: inside a git repo or some other repo? Apr 05 23:42:25 i have no idea Apr 05 23:42:31 it's a 3rd party file Apr 05 23:43:09 AbleBacon: Is it in DL_DIR/git2/XXX/somewhere ? Apr 05 23:43:15 no Apr 05 23:43:23 so are you saying i should just hunt this file down manually and put it in there? Apr 05 23:43:47 AbleBacon: no, I'm trying to understand what kind of file in DL_DIR you're having trouble with Apr 05 23:43:58 it's a .so file Apr 05 23:44:20 regardless, i deleted the corrupt file so i don't have it anymore anyway Apr 05 23:44:22 AbleBacon: you said "redownload one of the repositories" which suggested it was a git:// SRC_URI entry Apr 05 23:44:38 or maybe something like a subversion repo, I simply don't know Apr 05 23:44:41 i mean, it downlaoded the file from somewhere Apr 05 23:44:51 as part of the build Apr 05 23:45:15 usually if you remove the downloaded file it would re-download it Apr 05 23:45:57 AbleBacon: I assume you know which recipe is failing to build because of this? Apr 05 23:46:07 You could bitbake -c cleanall Apr 05 23:46:12 imx-gpu-sdk Apr 05 23:46:16 ah--ok i'll try that Apr 05 23:47:04 ok, thanks. it's fetching it again now Apr 05 23:50:50 hmmm now the VM crashed. ugh Apr 05 23:50:55 i was so close to completing the build Apr 05 23:57:23 eh, file truncated again **** ENDING LOGGING AT Fri Apr 06 03:00:00 2018