**** BEGIN LOGGING AT Tue Aug 01 03:00:00 2017 Aug 01 03:27:42 Hello there, I have a question. I am doing a core-image-minimal build, and I notice cdrtools-native is being build. Aug 01 03:27:47 how can I prevent it? Aug 01 03:27:54 sorry Aug 01 03:28:30 Good night everyone! Aug 01 06:42:25 good morning Aug 01 06:43:44 morning Aug 01 08:47:03 Morning all. I am checking over the licensing needs of my Yocto image. I have noticed that the ppp package is licensed under "BSD & GPLv2+ & LGPLv2+ & PD" according to the Yocto ouput. I took that to meant the old BSD 4-clause with advertising stuff in it. However when I look in the source output it has the generic_BSD file which seems to be the 3-clause license. Is that correct? Aug 01 08:52:58 hi all, having a problem turning my wifi adapter into an ap any idea? https://pastebin.com/HS1yBkcB <-- can someone help? Aug 01 08:57:23 TafThorne: The ppp package is mixed license, but "BSD" in terms of common licenses refers to the 3-clause (http://cgit.openembedded.org/openembedded-core/tree/meta/files/common-licenses/BSD). You can confirm this by looking at the source -> https://github.com/paulusmack/ppp/blob/master/pppd/ccp.c#L4 Aug 01 09:14:33 nrossi: thank you. I had found the source with the 3-clause in it. I was checking that BSD was the correct Yocto label for the 3-clause when I have also found BSD-4-Clause, BSD-3-Clause and BSD-2-Clause labels in there. Aug 01 09:15:52 I can understand the rational that 3-Clause is probably the more commonly used so having that listed for BSD makes some sense. It is always a little ambiguous when you allow multiple labels for one thing though. Aug 01 09:43:20 anyone? Aug 01 09:44:41 pagios: seems a hostap related question, not a yocto one :) Aug 01 09:51:18 I have built a working yocto linux image for my RK3288 board but I want to develop a custom chromium build for this. When I copy and attempt to run my ARM chromium build I get an error invalid file descriptor to ICU data received. How can I fix this error? Aug 01 09:52:29 wouterstreamit: add meta-webbrowser or howsitcalled, and then start with its preexisting chromium build :) Aug 01 09:53:09 LetoThe2nd: I tried that and that works, but I need to make changes to chromium (and want to use the latest version to start those changes from...) Aug 01 09:54:01 wouterstreamit: well then whats the problem with first bumping the version and then apply your changes from there? Aug 01 09:55:02 wouterstreamit: mind that the chromium build process is a bit special, so you might want to read up in the mailing list archives if there is some special reason why the version is not latest upstream Aug 01 09:59:03 LetoThe2nd: but my approach that disregards the meta-browser recipe is not generally supported in yocto Linux? I am assuming there are differences in the sysroots generated by the chromium build process and the one generated in yocto which causes the issues Aug 01 10:00:33 wouterstreamit: um, i don't get what you mean? meta-browser is under active development. the fact that its not directly included in oe-core is, well, due to the fact that we have layers and can seperate concerns. Aug 01 10:02:25 LetoThe2nd: I was trying to talk more generally, like suppose I have an existing image and want to compile and install an application that does not have a yocto recipe, this is not possible in yocto? Aug 01 10:03:14 wouterstreamit: it is technically possible through the use of an sdk, yet it is pretty painful at times. Aug 01 10:05:06 wouterstreamit: but in any way, you need an sdk that fits the image in use, otherwise the ABI might differ, and therefore stuff won't work Aug 01 10:38:30 hi, is there a recipe for airbase-ng? Aug 01 10:56:58 pagios, layers.openembedded.org Aug 01 11:17:10 hmm, debian8 on the (old) AB cluster has been stuck in adwaita-icon-theme run.do_install for a long time :-/ Aug 01 11:29:58 Crofton|work, airbase-ng airbasecrack and such are named what recipe/layer? Aug 01 11:30:27 pagios: why not open the link, click recipes in the header line, and search for yourself? Aug 01 11:31:05 LetoThe2nd, i cant find it this is why i am askign Aug 01 11:31:24 pagios: well then probably there are no recipes available at this point in time. Aug 01 11:31:29 ok Aug 01 11:47:29 LetoThe2nd, ok so i found aircrack recipe, i want to give it a shot in my meta-openembedded directory i cant find meta-security what can i do? Aug 01 11:49:21 pagios: look at the url of the recipe, download the layer, add it to your BBLAYERS Aug 01 11:50:27 LetoThe2nd, i did mkdir meta-security, and wget http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/tree/recipes-security/aircrack-ng/aircrack-ng_1.2.bb?h=master Aug 01 11:51:02 pagios: thank you for NOT listening Aug 01 11:51:30 pagios: seriously, haven't we been through all the beginner stuff already? Aug 01 11:52:13 pagios: so again. look at the repository where you found the desired recipe. the recipe is in a layer, something that usually starts with meta-XXX. in your case, meta-securoty Aug 01 11:52:38 pagios: now do a git clone of the layer, and checkout the branch that matches the rest of your build. Aug 01 11:52:55 pagios: after that, add the path to the layer to your conf/bblayers.conf, in the variable BBLAYERS Aug 01 11:57:23 ok thank you, i did it and igot this , now it means i need to add those layers too as dependencies? https://pastebin.com/txTWZDp8 Aug 01 11:58:17 pagios: read the documentation of the layer and decide for yourself: http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/tree/README Aug 01 12:03:56 LetoThe2nd, ok i got an expansionerror now: /sources/meta-security/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb: Failure expanding variable PACKAGECONFIG, expression was nss ${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)} which triggered exception AttributeError: 'module' object has no attribute 'filter Aug 01 12:04:01 lol Aug 01 12:05:07 thats a hard one for me Aug 01 12:06:58 have you *really* checked out the correct branch? Aug 01 12:09:01 LetoThe2nd, i did a git clone on git://git.yoctoproject.org/meta-security and then a checkout on fido Aug 01 12:10:26 and then did a git pull Aug 01 12:11:32 now: ERROR: Nothing PROVIDES 'aircrack-ng' Aug 01 12:13:25 seems aircrack not provided for fido LetoThe2nd Aug 01 12:15:11 it means i cant use it with fido right? Aug 01 12:15:21 Layer meta-security (master branch) Aug 01 13:28:09 is a yocto release EOLed at the release of two versions down? for example, is Morty EOL'ed Fall/2017? (from https://wiki.yoctoproject.org/wiki/Releases)? Aug 01 13:29:32 also, what is the consequence of being EOL'ed? can a project still utilize an EOL'ed release indefinitely? Aug 01 13:29:46 yates: EOL is a strong word, the community can and does submit patches, but its not officially supported. if you want a yocto release to be supported long, there's many commercial vendors that will support you for N years. Aug 01 13:30:37 rburton: patches to what? to bitbake? devtool? Aug 01 13:30:43 everything Aug 01 13:30:53 rburton: I'll make another attempt at fixing gperf breakage, then hack meson some more. ok with you? or any other things on your mind? Aug 01 13:31:00 kanavin: sounds good Aug 01 13:31:37 fray: didn't you say morty would be eol'ed in the fall? Aug 01 13:31:43 yesterday? Aug 01 13:32:00 10:16 morty is 2.2, which will be EOL (from a community perspective) this fall.. Aug 01 13:32:16 (forgot i'm still logged in) Aug 01 13:33:11 we don't freeze the repos, but contributions will reduce in volume and the maintainer for that release will stop being responsible Aug 01 13:33:34 i see. ok, thanks rburton Aug 01 13:47:06 rburton: what happened with the openssl 1.1 patches? Aug 01 13:49:54 kanavin: literally next on my queue in fact :) Aug 01 13:51:24 rburton: we need a better way for this (yes, you've heard this many times :) Aug 01 14:27:02 Does anyone know from where "uname -m" is pulling its information? According to one source, it's UTS_MACHINE as defined by the kernel. The utility is provided by busybox however, which also seems to be using UTS_MACHINE. However for a target like the zc706-zynq7 (meta-xilinx), UTS_MACHINE is "arm" and the runtime response of uname -m is "armv7l". Aug 01 14:27:52 uname comes from a kernel call. If it is munged by the utility it is wrong IMHO Aug 01 14:28:32 but really the key is busybox and coreutils/util-linux (don't rembmer which has uname) need to return the same values.. Aug 01 14:29:37 just looked.. appears to be the 'uname' system call which has a structure called utsname.. Aug 01 14:29:57 and yes, UTS_MACHINE seems like the vale that should be used Aug 01 14:33:03 on 32-bit ARM, UTS_MACHINE is inherited from the ARCH setting when building the kernel. Aug 01 14:33:17 armv7l is one of the arch values that may be passed into the kernel (as far as I can tell) Aug 01 14:34:02 YP sets the arch in 'kernel-arch.bbclass', appears to default to: Aug 01 14:34:03 export ARCH = "${@map_kernel_arch(d.getVar('TARGET_ARCH', True), d)}" Aug 01 14:34:59 elif re.match('armeb$', a): return 'arm' Aug 01 14:34:59 elif re.match('aarch64$', a): return 'arm64' Aug 01 14:34:59 elif re.match('aarch64_be$', a): return 'arm64' Aug 01 14:35:18 that is the map function, so assuming the kernel you are using, uses the standard behavior.. it SHOULD be setting 'arch' to 'arm' Aug 01 14:35:35 and thus UTS_MACHINE -should- be set to arm, and assuming nothing is munging it along the way, should come back out as arm Aug 01 14:35:56 some kernels set init_utsname()->machine to ELF_PLATFORM or UTS_MACHINE you have to check that for arch+kernel in question Aug 01 14:36:32 yup. board, kernel patches, arch stuff could all be slightly different.. I just did a quick run though of the morty kernel I had handy Aug 01 14:36:43 I'd take a step back and ask why you care where it comes from? What are you planning on using uname -m for, and why is what's there now not working for you? :) Aug 01 14:36:57 generally UTS_MACHINE is set to match kbuild architecture Aug 01 14:37:17 khem, yup.. I just wasn't sure where it was coming from (thus my explanation above) Aug 01 14:37:28 ...now I know... and knowing is half the battle... G.I. Joe! Aug 01 14:42:54 tgoodwin: check if kernel defines COMPAT_UTS_MACHINE Aug 01 14:57:29 YPTM: armin is on Aug 01 14:57:36 YPTM: stephano is on Aug 01 14:57:41 YPTM: - dial into: 1-800-262-0778 - enter the attendees number: 88748961 Aug 01 14:57:44 YPTM: Paul Eggleton is on Aug 01 14:57:47 YPTM: Stephen is on Aug 01 14:57:50 YPTM: Trevor Woerner is on Aug 01 14:59:44 YPTM: Joshua joined Aug 01 15:00:09 YPTM: Joshua Watt here Aug 01 15:00:46 Yes, my colleges laptop is slow Aug 01 15:01:08 YPTPM: Patrick Ohly joined. Aug 01 15:01:36 Interesting typo... I'm currently working with a TPM again... Aug 01 15:02:18 pohly: :-) Aug 01 15:02:30 YPTM: I'm on now Aug 01 15:03:52 lol Aug 01 15:03:58 :) Aug 01 15:04:15 YPTM: ross joined Aug 01 15:04:22 YPTM: Chris Larson on, though not awake Aug 01 15:04:25 * kergoth yawns Aug 01 15:04:46 dreyna has joined Aug 01 15:04:57 do 2.4 and 2.5 have names yet? Aug 01 15:05:05 tlwoerner: i think 2.4 does Aug 01 15:05:19 2.4 is rocko Aug 01 15:05:21 https://wiki.yoctoproject.org/wiki/Releases Aug 01 15:05:31 thanks Aug 01 15:14:09 YPTM is over. Aug 01 15:15:25 Does anyone know how `bitbake meta-toolchain` could generate a RFS with a different wordsize than the toolchain? Aug 01 15:16:05 If I compile with just toolchain, wordsize is 64, but if I add --sysroot=myrfs then wordsize becomes 32 Aug 01 15:16:16 you always need to pass --sysroot Aug 01 15:16:48 ythl: use the variables e.g. ${CC} to call the compiler, don't just call the binaries directly Aug 01 15:17:03 (the environment setup script sets those) Aug 01 15:17:31 I am doing that Aug 01 15:18:05 But the problem is that if I add `-std=c++11` compilation fails because word size is 32 when it needs to be 64 Aug 01 15:18:54 For some reason uintptr_t is a different size than void * Aug 01 15:19:49 If I don't pass sysroot, the toolchain uses its own internal sysroot, and it compiles Aug 01 15:20:07 But then I can't link against anything in the sysroot Aug 01 15:21:13 This is exactly my problem: https://stackoverflow.com/questions/45424272/gnu-gcc-bug-when-using-both-sysroot-and-c11?noredirect=1#comment77843733_45424272 Aug 01 15:44:17 How does the /usr/lib/sys folder get populated? I believe there's a bug in /usr/lib/sys/ucontext-32.h in my configuration Aug 01 15:49:01 ls Aug 01 16:10:55 wouterstreamit: you have to check which package provides this file Aug 01 16:11:00 We need to Aug 01 16:11:09 see if glibc is the one in this case Aug 01 16:18:45 kanavin: can you remember what recipes still expect a host python2 to build? Aug 01 18:01:15 khem: is there something I can help with go? Aug 01 18:19:56 otavio: there, is cgo, I dont know if it works all arches Aug 01 18:20:07 so may be thats something to look at Aug 01 18:21:04 khem: x86? i doubt it doesn't Aug 01 18:21:16 khem: also it builds fine, the binary gets elsewhere Aug 01 18:21:40 otavio: can you compare the configure logs for arm and x86 Aug 01 18:22:05 khem: is there something obvious I am looking for? Aug 01 18:22:09 I can for sure Aug 01 18:22:20 I can also get them somewhere for you Aug 01 18:22:31 yeah that would be helpful Aug 01 18:23:12 khem: but also it is easy to reproduce as the go-dep recipe works with qemuarm and fails with qemux86-64 Aug 01 18:30:01 khem: so do you want to test it there or want me to run it here? Aug 01 18:37:07 otavio: my guess is that its because of host and target being x86 something is not cross compiling right Aug 01 18:37:22 do you see this issue on say ppc or mips ? Aug 01 18:37:25 or aarch64 Aug 01 18:38:45 khem: i did not try them Aug 01 18:53:15 you could try building it inside a qemu and see where it installs it natively on say qemuarm Aug 01 19:08:11 kergoth: It's metadata that gets added to an XML file and checked at runtime by the machine. If the value doesn't match what the runtime (compiled) utility reads from uname -m, it fails. Aug 01 19:11:24 fray: thanks for the suggestions. I'm still trying to figure out why Xilinx's zc702-zynq7 machine manages to output something different than UTS_MACHINE. The ARCH gets set to arm repeatedly according to the logs from configuring and comipling the kernel, but armv7l ends up baked into the binaries. Aug 01 19:12:41 khem: also, I don't see COMPAT_UTS_MACHINE or ELF_PLATFORM used in either case (busy box or the kernel). Aug 01 19:13:15 (Sorry for the multi-hour delay in responding. Had some fires to put out.) Aug 01 20:06:22 khem: I did not follow what you mean Aug 01 20:15:50 Hi in /etc/systemd/system i have busybox-udhcpc.service Aug 01 20:16:10 how can i enable this service to run on startup via recipies Aug 01 20:17:29 otavio: I mean build is natively on arm using qemuarm Aug 01 20:31:09 I am not sure what you are looking for here; building locally does not use GOBIN_FINAL and other variables Aug 01 20:34:52 anyway, I was trying to help you debug this Aug 01 20:35:09 so we know what it could be causing it Aug 01 20:38:26 khem: sure; I just don't know what to look for. I will test qemux86 and see if it fails too Aug 01 20:54:03 khem: indeed; when the arch matches the host arch it fails; otherwise it works Aug 01 20:54:32 qemux86 also works as my host machine is x86-64 Aug 01 21:02:26 khem: http://termbin.com/bhiq and http://termbin.com/3hju Aug 01 22:11:39 dreyna: by the way, you weren't recorded as having attended the YPTM because you didn't prefix your "dreyna has joined" with "YPTM: " ;-) Aug 01 22:12:06 ah, ok Aug 01 22:51:36 is it possible to use a Yocto recipe to append onto an environment variable defined in say a Makefile for a recipe that grabs source for compilation? **** ENDING LOGGING AT Wed Aug 02 03:00:01 2017