**** BEGIN LOGGING AT Tue Apr 23 02:59:57 2019 **** BEGIN LOGGING AT Tue Apr 23 07:43:30 2019 Apr 23 07:48:01 LetoThe2nd, hmm Apr 23 07:49:12 xtron: maybe show the line *VERBATIM* in a pastebin or such. Apr 23 07:59:31 LetoThe2nd, looking for the culprit "source_mirror_url" Apr 23 08:47:01 kergoth: no objection from me Apr 23 12:13:59 hi, need some help, i am in systemd-nspawn but building (cloning repos) a yocto recipe i get the GIT : fatal: index-pack failed Apr 23 12:14:55 more proper error, just before, is : fatal: The remote end hung up unexpectedly Apr 23 12:25:42 RP, I am traveling today to I wont look at swat till later tonight Apr 23 12:28:23 armpit: no problem. I'm going to rerun master-next with iputils dropped, I think that is the cause of most of the problems Apr 23 12:28:40 k Apr 23 12:29:20 I added you to the bug regarding the timeouts as I saw them on master as well as thud Apr 23 12:30:07 armpit: thanks, I noticed those too :( Apr 23 12:30:18 seems like the same systems Apr 23 12:31:31 armpit: did we note which machines and which steps/targets in the bug? Apr 23 12:31:41 I did Apr 23 12:32:27 thanks! Apr 23 12:33:09 armpit: I wonder if this was the NAS failure? Apr 23 12:33:33 thats what I thought too but the master build came after Apr 23 12:33:37 the fix Apr 23 12:33:56 hmm :( Apr 23 12:34:53 the mater build I looked at was last night "Mon Apr 22 08:50:19 2019 " Apr 23 12:35:20 it has the {ak} notes added Apr 23 12:36:49 armpit: could it have started before the nas trouble and only finished afterwards? Apr 23 12:40:06 that was the start time Monday morning Apr 23 12:40:27 don't know TZ for the AB Apr 23 12:40:53 huh? Apr 23 12:40:59 oh timezone Apr 23 13:36:26 hello! I have a problem with /etc/inittab file - I added some customization (using sysvinit-inittab_2.88dsf.bbappend file ), I can confirm that my changes exists inside *.rootfs.ext4 image , but whan I boot it with qemu - my changes are gone, there is only default inittab file.... what may alter it ?? Apr 23 13:47:18 Hi, while looking to the file openssh_6.7p1.bb, I see RCONFLICTS_${PN} = "dropbear". If I well understand it means that any version of openssh is in conflicts with any version of dropbear. But what's means RCONFLICTS_${PN}-sshd = "dropbear" ? Apr 23 13:57:37 anyone could see a reason why a patch would be listed in log.do_patch as successfully applied, but not applied in fact (and running "quilt push" manually in ${S} would in fact apply it properly) ? Apr 23 13:59:43 yann, which version of yocto is that? Apr 23 13:59:49 warrior Apr 23 13:59:51 erakis: these are package manager directives that apply to packages, not recipes Apr 23 14:00:25 erakis: so its creating the conflicts for ${PN} (the openssh package) and ${PN}-sshd, the openssh-sshd package Apr 23 14:00:57 armpit: https://autobuilder.yoctoproject.org/typhoon/#/builders/57/builds/517 needs a bug, looks like a makefile race :( Apr 23 14:04:11 RP: So from the recipe of openssh, we can set a conflicts from another pakcage (in this case openssh-sshd) ? Apr 23 14:04:54 erakis: the openssh recipe generates multiple packages, openssh and openssh-sshd are two of them Apr 23 14:07:39 RP: Ok, I understand now. I have always thought that a recipe can only produce a single package as we only have a single variable for the package name $PN. Apr 23 14:08:11 erakis: it creates the list of packages in PACKAGES Apr 23 14:08:33 erakis: PN would be better called recipe name Apr 23 14:21:01 RP: Oops, I did not see that one. https://www.yoctoproject.org/docs/1.0.2/poky-ref-manual/poky-ref-manual.html#var-PACKAGES. Thank you so much. Apr 23 14:21:14 RP: Now I fully understand ;) Apr 23 14:25:25 rburton, nice to see you back :) Apr 23 14:26:15 yann, the only thing I can think of, and it is highly unlikely to happen, is that the patch is applied, but into the wrong place in the file Apr 23 14:26:29 RP: Could you give me more information on how to reproduce the test images (core-image-sato-ptest) from the tests link you provided me. https://autobuilder.yocto.io/pub/non-release/20190417-10/testresults/qemux86-64-ptest/testresults.json Apr 23 14:26:31 if the context is matching exactly Apr 23 14:26:40 My google fu yield nothing Apr 23 14:28:09 kanavin: quite unilikely I'd say, the patch rewrites most of a single file - how would it be possible that "quilt push" does the job when do_patch does not ? Apr 23 14:28:40 and when do_patch does not even record (for quilt) the patch to be applied Apr 23 14:29:52 just in case I'm pulling the tip of warrior, I was 2 weeks behind Apr 23 14:29:57 RP: Sorry for the newbie question. I have last one for you. What's the default value of RREPLACE and RCONFLICTS ? I've look into "meta/conf/bitbake.conf" but I did not found anything conclusive. Previously I had a recipes without version "my-program.bb". Now I renamed it to "my-program_1.1.0.bb". If I install the new package, is the old one will be in conflicts and replaced ? If no, how I can make the old one being conflicts of the new one ? Moreover, what Apr 23 14:29:57 will happens when I will call "opkg upgrade", will the new package be considered newer? Apr 23 14:34:55 all that changed is the version, so it will just upgrade Apr 23 14:38:18 rburton: Reassure me, so if I renamed a recipes from "my-program_1.1.0" to "my-program_1.0.0", doing "opkg upgrade" will not pick it ? Apr 23 14:38:39 correct, thats a downgrade Apr 23 14:38:54 default PV assuming you didn't touch it in the recipe itself is 1.0 Apr 23 14:39:16 (a recipe without a version in the filename uses the default PV=1.0) Apr 23 14:42:10 New news from stackoverflow: Yocto - Bitbake RDEPENDS from External Shared library Apr 23 14:47:16 rburton, would you be sending recipe updates from the most recent AUH run? Apr 23 14:48:07 and would Anuj? just looking at the list of things to be updated and thinking what I could pick up, but it has to be from a truly absent maintainer Apr 23 14:48:26 e.g. python* maintainer is truly gone Apr 23 14:51:03 psrcode: basically add http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=96e4294209b992bf1b7ebea75e9e049b36bbe95b to master-next Apr 23 14:51:23 psrcode: I couldn't merge it since it doesn't work so well :( Apr 23 14:53:44 RP: okai good I'm not crazy :P Apr 23 14:54:31 kanavin: most of my latest run was failures Apr 23 14:54:36 I should be able to work on that by next week Apr 23 14:54:37 kanavin: i will yes. but not today Apr 23 14:57:42 psrcode: no, but I wonder about me ;-) Apr 23 14:59:10 it would be nice if the testresult contained the git remote used. is this information already available somewhere? Apr 23 14:59:31 rburton, sure, all fine then Apr 23 15:00:51 kanavin: seems it's fixed with current warrior, sorry for the noise Apr 23 15:03:16 psrcode: the trouble is that remote rebases :/ Apr 23 15:07:56 well having the "base" remote would have helped me understanding the status/nature of that run, I tought it was an existing build/test job failing. anyway will take a look into it. Apr 23 15:24:58 anyone ever setup adb on a yocto setup? I installed the pkg but trying to figure out the right kernel modules needed to do adb over USB. adb over network works fine Apr 23 15:27:49 psrcode: yes, the intention was it would be going into master, the results were just bad enough we couldn't which was unusual Apr 23 16:57:16 kanavin: can you build mesa with and without your latest patchbomb? here, mesa changes. Apr 23 16:57:26 --rwxr-xr-x root root 65018064 ./usr/lib/dri/.debug/kms_swrast_dri.so Apr 23 16:57:26 -rwxr-xr-x root root 88267032 ./usr/lib/dri/.debug/nouveau_vieux_dri.so Apr 23 16:57:27 +-rwxr-xr-x root root 65018064 ./usr/lib/dri/.debug/virtio_gpu_dri.so Apr 23 17:01:12 rburton: the one in -next? Apr 23 17:01:42 yeah based on next Apr 23 17:01:44 rburton: btw, we will now get some ptest results in quick builds: https://autobuilder.yocto.io/pub/non-release/20190423-7/testresults/testresult-report.txt Apr 23 17:02:05 or best rebase Apr 23 17:03:06 rburton: I mean is it kanavin's patchbomb in -next or the one from today Apr 23 17:05:28 "PKGR changed from r0 [default] to r0.0" - not helpful buildhistory :/ Apr 23 17:05:38 (from https://autobuilder.yocto.io/pub/non-release/20190423-7/testresults/qemux86-64/buildhistory.txt) Apr 23 17:46:54 Hm, think I just found a strange bug regarding runtime mappings for multilib as it applies to runtime packages and their preferences. I have PREFERRED_PROVIDER set without using MLPREFIX, relying on the automatic mapped versions being set, and I have a FEATURE_PACKAGES which installs a package that this recipe emits. If I build lib32-core-image-base, RDEPENDS includes the lib32 variant binary package name, but it's not obeying the implicitly set Apr 23 17:46:54 preference with that mlprefix, i had to explicitly set the preference including mlprefix to get it to obey the pref for this binary package installation. core-image-base and lib32-core-image-base were bujilding and installing two different providers, despite the preference being set. Apr 23 17:49:05 To clarify, I was forced to do PREFERRED_PROVIDER_${MLPREFIX}foo = "bar", even though bitbake -e shows that PREFERRED_PROVIDER_lib32-foo = "lib32-bar" already. Apr 23 17:49:36 Maybe an order of operations issue, the mapped preference set after it tried to look it up for the image RDEPENDS? Apr 23 17:50:17 that doesn't make sense, though.. Apr 23 18:11:57 Is anyone using valgrind as a native tool, for instance for running unit tests? Apr 23 19:27:50 guys, sumo is missing this bugfix: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761 Apr 23 19:27:51 Bug 84761: was not found. Apr 23 19:28:10 therefore asan will not work on x86 32bit programs Apr 23 19:34:44 shall i file a bug or isn't sumo worth it? :> **** ENDING LOGGING AT Wed Apr 24 02:59:57 2019