**** BEGIN LOGGING AT Sat Sep 26 02:59:57 2020 Sep 26 05:35:30 RP: something is broken on master-next https://errors.yoctoproject.org/Errors/Build/110274/ Sep 26 07:21:41 khem: yes, I missed a patch, sorry :/ Sep 26 07:32:50 RP: base: Rework and improve do_unpack WORKDIR cleanup from previous builds seems to be bad one Sep 26 07:53:52 khem: yes, it was missing a meson fix for that Sep 26 09:48:19 how can I submit a backport from master to dunfell? Sep 26 10:03:56 mihai: send a patch with [dunfell] in the subject? Sep 26 10:04:37 mihai: cc Steve Sakoman (or if its a straight cherry-pick reply to the patch and cc steve and ask for the backport) Sep 26 10:24:51 RP: it's a straight cherry pick, thanks Sep 26 11:00:42 I've been moving my local.conf stuff to what I thought was the correct locations in distro/x.conf and machine/x.conf, and suddenly I'm getting license issues Sep 26 11:01:26 getting warnings like "do_rootfs: The license listed GPLv2 was not in the licenses collected for recipe glibc" Sep 26 11:02:05 and a hard error in the python license task saying that it couldn't find "linux-yocto/.../recipeinfo" Sep 26 11:14:47 I ran cleanall on both of them, but I'm not sure why they were missing in the first place...I haven't removed them at any point and everything was fine before I stared reorganizing stuff to start creating my production build Sep 26 14:26:52 RP: pseudo changes are perhaps to blame for https://errors.yoctoproject.org/Errors/Build/110378/ Sep 26 14:27:47 khem: its the do_unpack ones Sep 26 14:28:04 khem: I've pushed several fixes to master-next over the last few hours but its looking like its a painful change :( Sep 26 14:28:40 khem: do_populate_lic and lsof fixes are definitely there, not sure about the others Sep 26 14:29:34 OK Fired a new build with latest master-next lets see Sep 26 14:30:21 khem: the user errors in the do_package_qa could be pseudo or they could be genuine problems being exposed, hard to tell Sep 26 14:30:33 there are also some do_package_qa issues there in the list Sep 26 14:30:50 they seem to be happening on all machines Sep 26 14:31:24 and consistently failing on every build Sep 26 14:32:29 khem: I just saw a related error on the main autobuilder so there is something pseudo related wrong in there :( Sep 26 14:32:31 my VMs ran 8 different builds overnight Sep 26 14:33:16 usually I have seen these errors in past when pseudo crashed mid-way Sep 26 14:37:36 RP: I am trying ptest runs on images, few fails in glib-2.0 are showing up perhaps will try to see whats going on Sep 26 14:50:33 khem: alex did a good job of sorting out a lot of ptest results so they should be passing but we've not really looked much outside the targets core tests Sep 26 14:53:11 khem: that autobuilder issue broke locally too. This did work so I wonder what changed :/ Sep 26 15:16:26 khem: repushed master-next with a pseudo fix, will restart the builds Sep 26 15:36:05 hmm, still not right Sep 26 15:37:37 hello, good morning! Sep 26 16:54:12 khem: I'm going to have to abandon that do_unpack patch, it just won't work Sep 26 17:16:45 Hi all, I am cloning fsl-community-bsp-platform on the dunfell branch on a Linux Mint host and I am bumping into the sanity checker error when checking long filenames. I have given the crops/poky:ubuntu-1804 docker image a go to build but same error. It seems to stem from the fact my home directory, like most Ubuntu based home directories who accept the defaults, is eCryptFS on EXT4. It doesn't seem like an uncommon build environment so is there a Sep 26 17:16:45 workaround or do I really need to partition a build area in straight EXT4? Sep 26 17:30:36 Wipster: yes, you'll need to use a build dir outside ecryptfs Sep 26 17:37:32 mihai: ouch ok, thank you for the definitive answer Sep 26 23:57:58 RP: right, it failed for me too **** ENDING LOGGING AT Sun Sep 27 03:02:40 2020