**** BEGIN LOGGING AT Sat Oct 29 03:00:00 2016 Oct 29 15:48:37 seen elsewhere: The Programmer's Credo: We do these things not because they are easy, but because we thought they would be easy. Oct 29 15:48:41 This is *exactly* why pseudo exists. Oct 29 15:51:57 (and exactly why user namespaces exist, too? ;-)) Oct 29 15:52:31 probably. Oct 29 17:07:07 hmm, pseudo fails to build from source on x32: https://buildd.debian.org/status/fetch.php?pkg=pseudo&arch=x32&ver=1.8.1%2Bgit20161012-1&stamp=1477757121 Oct 29 17:07:12 seebs: any ideas? Oct 29 17:07:50 Huh. Now I have to remember why we had a specific version requested for memcpy. Oct 29 17:08:17 seebs: by the way, could you import a manpage patch from Debian? Oct 29 17:08:32 #ifdef __amd64__ Oct 29 17:08:32 GLIBC_COMPAT_SYMBOL(memcpy,2.2.5); Oct 29 17:08:33 this one: https://sources.debian.net/src/pseudo/1.7.5-5/debian/patches/0000-manpage.patch/ Oct 29 17:08:49 Yeah, it's on my list. I'm briefly between development machines, but I've got an email with it. Oct 29 17:08:55 So why is x32 defining __amd64__? Oct 29 17:09:07 honestly, I don't know Oct 29 17:09:21 I guess the likely fix would be to find a suitable #ifdef for x32 and change it to if defined(__amd64__) && !defined(...) Oct 29 17:09:55 Not 100% sure that's the issue, but it's my first guess, since that's the only way I'd expect to see a memcpy@GLIBC_2.2.5 show up. Oct 29 17:10:26 seebs: a-ha, I see Igor Gnatenko has forwarded it Oct 29 17:12:08 seebs: https://wiki.debian.org/X32Port#Detecting%20_X32 Oct 29 17:15:02 ports/linux/portdefs.h: Oct 29 17:15:03 -#ifdef __amd64__ Oct 29 17:15:03 +#if defined(__amd64__) && !defined(__ILP32__) Oct 29 17:15:12 try that and let me know whether it works before I push any commits? Oct 29 17:25:07 doing so Oct 29 17:51:59 seebs: I uploaded a patched version, I expect build results to be ready shortly. Oct 29 18:06:21 Thanks! Oct 30 00:08:08 seebs: https://buildd.debian.org/status/fetch.php?pkg=pseudo&arch=x32&ver=1.8.1%2Bgit20161012-2&stamp=1477764616 Oct 30 00:08:51 seebs: I used this patch: https://sources.debian.net/src/pseudo/1.8.1%2Bgit20161012-2/debian/patches/0001-fix-x32-build.patch/ Oct 30 00:55:57 I'm having an issue creating this recipe from a git repo. I don't understand all of the path variables. I have SRC_URI = "git://github.com/OpenZWave/open-zwave.git" Oct 30 00:56:24 Then if I do LIC_FILES_CHKSUM = "file://git/license/license.txt;md5=584c7ddacb8739db77ddcc47bd9d3b52" it doesn't find the license file Oct 30 00:58:04 and when I peek in devshell it has me in /openzwave/1.0-r0/openzwave-1.0 and seems to try to run make from there instead of /openzwave/1.0-r0/git Oct 30 00:59:25 This is what my recipe looks like along with the console output from devshell when i was poking around https://gist.github.com/lolsborn/266dc03c19060f2fd9c97a9597dc0220 Oct 30 01:21:24 It's like it thinks the code is a directory deeper than it has installed it. plus /openzwave/1.0-r0/openzwave-1.0 seems redundant Oct 30 01:24:19 lolsborn: LIC_FILES_CHKSUM is relative to S. S already includes the 'git' portion of that path Oct 30 01:28:06 So if I change it to LIC_FILES_CHKSUM = "file://license/license.txt;md5=584c7ddacb8739db77ddcc47bd9d3b52" I still get LIC_FILES_CHKSUM points to an invalid file: /home/ubuntu/mender-work/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/openzwave/1.0-r0/openzwave-1.0/license/license.txt Oct 30 01:28:24 The reason why is the file is actually in /home/ubuntu/mender-work/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/openzwave/1.0-r0/git Oct 30 01:28:41 It's adding /openzwave-1.0/ as an empty directory Oct 30 01:28:55 and S seems to be pointing there Oct 30 01:38:21 you have S wrong, then Oct 30 01:38:25 set S = "${WORKDIR}/git" Oct 30 01:38:28 that's required when using the git fetcher Oct 30 02:18:46 Thanks kergoth, that fixed the license issue. I have another path question though. It's failing when running make because it's running from openzwave/1.0-r0/build Oct 30 02:18:57 but everything is in openzwave/1.0-r0/git Oct 30 02:19:36 Do I need to update the build directory variable too? Oct 30 02:20:46 setting b = s seems to do the trick. Is this typical? Oct 30 02:41:30 lolsborn: you'd be better off just fixing the buildsystem of the project you're building to support out of tree builds properly, but yes, lacking that, reverting B to S is an option Oct 30 02:42:18 Ok, I see what you're saying. Thanks kergoth Oct 30 02:42:22 andrewsh: that looks like it worked, then? If so I'll go ahead and push that to master, and consider it probably resolved for now. **** ENDING LOGGING AT Sun Oct 30 02:59:59 2016