**** BEGIN LOGGING AT Wed Nov 23 03:00:00 2016 Nov 23 08:53:37 hi Nov 23 10:24:10 tried switching from rpm to deb for my builds, also added dpkg package as IMAGE_INSTALL_append Nov 23 10:24:15 dpkg: warning: package architecture (armhf) does not match system (amd64) Nov 23 10:24:37 multiple failures such as these... any idea on what is wrong? Nov 23 10:51:24 eduardas_m: deb is the least tested backend, i recommend using opkg or rpm Nov 23 11:00:20 Should I use PACKAGE_EXCLUDE to exclude a recipe of being build? e.g: qemu Nov 23 11:01:45 Hi ! I'm looking for producing ipk files for my MACHINE "hachiko64", but every ipk goes to "cortexa9hf-vfp-neon". I'm sure it's simple but I couldn't find an answer on the doc (don't know where to look). Can you help me ? Nov 23 11:01:47 neverpanic: most of those patches look good, just wondering about the pseudo one. I think we specified all the variables just to be very sure what it was doing Nov 23 11:04:57 Kakounet: whats your question? Nov 23 11:06:30 aV_V: I've made a receipe "udpclient" and it produces a ipk in "/ipk/cortexa9hf-vfp-neon", I want that it also produces an ipk in "/ipk/hachiko64" Nov 23 11:07:40 rburton, aren't yocto releases supposed to be tested automatically for various package systems? Nov 23 11:07:42 aV_V: because I want to use opkg Nov 23 11:08:14 eduardas_m: yes, but bugs sneak in that the autobulder doesn't cover. Nov 23 11:08:16 Kakounet: why? hachiko64 folder stores the kernel and kernel-modules packages Nov 23 11:08:43 cortexa9hf-vfp-neon folder stores the packages for ur distro Nov 23 11:09:16 u only need to add that folder too as a source channel Nov 23 11:09:20 aV_V: aahhh ! Ok, I thought it was a mistake I made Nov 23 11:09:37 aV_V: Thanks, I will test it :) Nov 23 11:10:28 rburton, can it be that a new package system requires a new build folder? because I just edited the local.conf of the folder I was doing my rpm builds in Nov 23 11:10:52 nope, i build all three at once Nov 23 11:11:13 trying to build in fresh new build folder right now Nov 23 11:11:14 Kakounet: remember to update ur repo index every time u generate/modify a new package: bitbake package-index Nov 23 11:11:20 will see how it goes Nov 23 11:12:17 aV_V: Yep, did it. I have to change the folder of the server to point to all I guess (I'm under dora, so I use opkg) Nov 23 11:13:45 Kakounet: yes Nov 23 11:15:57 wait... you can build all three types of same packages at once? what would that require in local.conf? Nov 23 11:16:16 also, what defines what type of package goes into final image then? Nov 23 11:18:49 eduardas_m: PACKAGE_CLASSES=package_deb package_ipk package_rpm Nov 23 11:18:55 the image type is the first entry in the list Nov 23 11:19:24 or as the local.conf template says Nov 23 11:19:24 # This variable lists which packaging formats to enable. Multiple package backends Nov 23 11:19:25 # can be enabled at once and the first item listed in the variable will be used Nov 23 11:19:25 # to generate the root filesystems. Nov 23 11:19:25 :) Nov 23 11:21:56 rburton, thanks a lot... that is good to know. But what is the practical benefit of building all three? Nov 23 11:22:13 eduardas_m: just testing, really Nov 23 11:27:45 rburton, my motivation for using deb is the "OpenEmbedded in the Real World by Scott Murray" video I watched yesterday... since it says there are no recipes in OE for yum or dnf, but there is one for apt Nov 23 11:28:08 just want to see whether there is any benefit Nov 23 11:29:50 RP: I don't think the extra variables are necessary, because pseudo's recipes seems to always configure for those paths anyway Nov 23 11:30:23 Looking at the pseudo code, it'll arrive at the same paths without those variables, but that might have been different with older pseudo versions? Nov 23 11:38:25 neverpanic: I think it was belt and braces and also to aid debugging but I don't exactly remember Nov 23 12:33:49 rburton, still getting dpkg failures when doing rootfs... it looks to me that yocto is trying to use my development host version of dpkg which is unsuitable Nov 23 12:34:21 dpkg: warning: package architecture (armhf) does not match system (amd64) Nov 23 12:36:28 no, I am actually wrong, yocto is using dpkg from the proper sysroot Nov 23 12:36:41 but still huge failures Nov 23 12:37:03 this is part of the error log: Nov 23 12:37:09 Unable to install packages. Command '/home/eduardas/BigDisk/var-mx6ul-mx7-yocto-krogoth/build-fb-deb/tmp/sysroots/x86_64-linux/usr/bin/apt-get install --force-yes --allow-unauthenticated packagegroup-core-ssh-dropbear psplash tcf-agent packagegroup-core-tools-profile u-boot-fw-utils imx-kobs util-linux-sfdisk qtbase-plugins openssh-sftp-server packagegroup-fsl-tools-audio packagegroup-fsl-tools-benchmark brcm-patchram-plus qtbase-examples Nov 23 12:37:09 kernel-modules qtbase-fonts fio qtbase packagegroup-core-full-cmdline packagegroup-core-tools-testapps packagegroup-fsl-gstreamer1.0-full packagegroup-core-nfs-server packagegroup-fsl-tools-gpu-external runonkeyrls packagegroup-fsl-gstreamer1.0 packagegroup-fsl-tools-gpu packagegroup-fsl-tools-testapps run-postinsts u-boot-splash bcm4343w-fw packagegroup-core-tools-debug minicom hostapd packagegroup-tools-bluetooth packagegroup-core-boot tslib-tests Nov 23 12:37:09 packagegroup-base-extended tslib-calibrate' returned 100: Nov 23 13:07:31 neverpanic: I now understand why you don't see useradd errors with oe-core. Sadly we don't have good tests in oe-core for things like intrapackage user additions Nov 23 13:07:56 neverpanic: I think your code will also struggle with partial builds from sstate :/ Nov 23 13:08:11 neverpanic: (I'm trying to figure out if I'm overcomplicating mine) Nov 23 13:11:26 RP: Where do you expect problems with sstate? In combination with useradd.bbclass you mean? Nov 23 13:17:06 neverpanic: if for example dbus do_package is restored from sstate, would the recipe specific sysroot have the right group/user setup to allow the sstate package to extract successfully? Nov 23 13:18:41 neverpanic: worse is the case that you have a recipe A which relies on the messagebus user being created by the dbus package Nov 23 13:21:11 Oh, yeah, that probably doesn't work, because there are different /etc/passwd files and no mechanism to merge them Nov 23 13:21:23 I must admit I didn't think of this case :/ Nov 23 13:21:40 Your sstate-based approach should be able to deal with that, though, shouldn't it? Nov 23 13:22:02 neverpanic: yes, I hope so. I'm just trying to see whether I'm making this harder than I need to :) Nov 23 13:26:32 hi, I'm getting an error on do_rootfs: warning: user daemon does not exist - using root Nov 23 13:26:44 when it is installing my package Nov 23 13:26:58 but I have two packages that runs chown daemon:daemon Nov 23 13:27:22 one works and the other one shows this error Nov 23 13:27:42 anyone know why? Nov 23 13:28:50 Is the dependency missing? Unless your creating the user in the package you need to make sure your are creating the user first Nov 23 13:29:16 this user is default on etc/groups Nov 23 13:29:29 it works on do_install Nov 23 13:29:40 I put base-passwd as dependency Nov 23 13:29:56 but this error is happening on do_rootfs of the image Nov 23 13:30:04 when it is installing the packages with smart Nov 23 13:32:30 I am receiving the QA host contamination warning even though I've made sure the ownership of the file belongs to user X Nov 23 13:32:32 install -g nautel -o nautel -m 644 ${S}/config.scm ${D}/nautel/snmp/config.scm Nov 23 13:32:46 I've tried chown nautel:nautel -R ${D} Nov 23 13:32:58 What else could it be? Nov 23 13:35:26 I've set KERNEL_MODULE_AUTOLOAD += "ads7846" but it didn't work. Why? Nov 23 13:51:29 aV_V: did the entry get into you rootfs? /etc/modules-load.d/*.conf Nov 23 13:52:54 nrossi: no, is empty Nov 23 13:55:20 aV_V: You have added the "kernel-module-foo" to your image correct? Nov 23 13:55:57 nrossi: I didn't Nov 23 13:56:09 aV_V: Well there is your problem ;) Nov 23 13:56:18 I need to add it to IMAGE_INSTALL? Nov 23 13:56:26 aV_V: yep Nov 23 13:57:03 In fact, I was searching something like that but didn't find any ads7846 recipe Nov 23 13:57:41 from where it come that kernel-module-foo? Nov 23 13:58:12 aV_V: "kernel-module-ads7646" would be the name of the package. Assuming though you kernel is configured to compile that as a module Nov 23 13:58:31 sorry "kernel-modules-ads7846" Nov 23 13:59:09 nrossi: I thought when u specify packages on IMAGE_INSTALL, then it must be a recipe for that package Nov 23 14:00:02 aV_V: IMAGE_INSTALL is packages, kernel-module-* is dynamic packages generated by the kernel Nov 23 14:00:15 (kernel recipe) Nov 23 14:01:03 nrossi: Ok, so modules work that way Nov 23 14:01:05 THanks Nov 23 14:36:50 aV_V, is there a tangible benefit for your application to use the driver as a kernel module instead of making it built-in? Nov 23 14:37:56 eduardas_m: hi! Didn't test it yet Nov 23 14:39:04 I got 40-50 fps testing cinematicexperience with the builtin version, now I will try the module Nov 23 14:41:12 So how do most people manage their Yocto distribution? Nov 23 14:43:37 What I'm thinking is something like: clone poky, create a branch for my own project where I commit my local.conf and bblayers.conf, etc. and then have a script that pulls in external layers (like meta-whatEverINeed)? Nov 23 14:44:36 don't commit your local.conf, write a custom distro config that you commit Nov 23 14:45:02 I am receiving the QA host contamination warning even though I've made sure the ownership of the file belongs to user X Nov 23 14:45:02 then your local.conf shoud just be the template with DISTRO=mydistro Nov 23 14:45:07 install -g nautel -o nautel -m 644 ${S}/config.scm ${D}/nautel/snmp/config.scm Nov 23 14:45:11 I've tried chown nautel:nautel -R ${D} Nov 23 14:45:16 What else could it be? Nov 23 14:46:31 rburton: mydistro can be based on poky? Nov 23 14:46:55 aV_V: poky is almost nothing over the default Nov 23 14:47:12 feel free to copy poky.conf and delete the bits you don't care about Nov 23 14:47:30 nice Nov 23 14:47:31 ie SANITY_TESTED_DISTROS isn't relevant for *your* distro unless you test it on all of those distros Nov 23 14:48:38 So are there any built in mechanisms for pulling in other layers, or was I correct in assuming I would need to manage that myself? Nov 23 14:49:02 i.e. pulling in a layer from a git repo or tarball or whatever? Nov 23 14:52:51 your choice Nov 23 14:52:58 repo, git submodules, whatever Nov 23 14:53:31 Ok.. but how? Where? Nov 23 14:54:19 ? repo is a tool from google, git submodules is a standard git tool Nov 23 14:54:42 Yes. Nov 23 14:54:58 We are so far from being on the same page, right now ;) Nov 23 14:55:40 How do configure my external/remote layers? Do I just add the URI to BBLAYERS and it pulls it automatically? Nov 23 14:56:09 because right now, my BBLAYERS are all local directories.. Nov 23 14:56:49 layers have to be local directories, yes Nov 23 14:56:54 You'd use git submodules/repo/whatever to bring in the layers locally Nov 23 14:56:55 you arrange to clone them yourself and point to the local cloned path Nov 23 14:56:57 * kergoth yawns Nov 23 14:57:38 Ahh, exactly. So there ISN'T a built-in mechanism to pull them. Nov 23 14:58:18 indeed, rburton was referring to the third party tools you could use to do it, not built-in mechanisms Nov 23 14:58:19 yeah, that's why i said "your choice" :) Nov 23 14:58:33 Ok, cool Nov 23 14:58:36 Thanks :D Nov 23 14:58:43 Both of you :) Nov 23 14:59:24 totally OT, but https://github.com/pypa/pipfile seems interesting Nov 23 15:00:07 wouldn't be the first time someone tried to replace requirements.txt, but we shall see Nov 23 15:00:30 haha Nov 23 15:00:56 JoiF -- check out the new component: https://github.com/Wind-River/wr-lx-setup Nov 23 15:01:22 we're working on that to help manage initial project creation. It uses the layer index (public or your own if you have one) to figure out what to download for a project.. Nov 23 15:01:38 thread introducing it: Nov 23 15:01:39 http://lists.openembedded.org/pipermail/openembedded-architecture/2016-November/000310.html Nov 23 15:02:12 hope is once the public layer index is handling the distro setting, we can look at making this a part of OpenEmbedded itself.. Nov 23 15:03:05 * CTtpollard would prefer not to rely on Google tools in OE Nov 23 15:03:17 Ok Nov 23 15:03:19 Nice Nov 23 15:04:31 CTtpollard? Nov 23 15:04:31 the program is broken into two parts.. resolving the items and constructing the repo file. I need to use repo for my own purposes, but I'm open to someone working through the code and doing and alternative for the repo functions Nov 23 15:04:50 create a new python module and move the repo, submodule, hg, or whatever into there.. Nov 23 15:05:03 the actual processing of the index and determinging everything needed would be common no matter what the backend is Nov 23 15:05:04 Ahh, it's using repo. Nov 23 15:05:23 Didn't get where CTtpollard was coming from at first Nov 23 15:05:25 (from the people I've talked to over the past few years, repo is the most common approach I've seen.) Nov 23 15:22:58 eduardas_m: I'm getting the same performance testing cinematicexperience with the fscl-community driver Nov 23 15:29:11 okay, it's annoying that postinst intercepts are hardcoded to a specific path Nov 23 15:29:22 makes it so another layer can't override or extend / add intercepts Nov 23 15:29:28 this should really be searching bbpath Nov 23 15:32:48 kergoth: i'd love to rewrite the intercept stuff Nov 23 15:33:01 so i'd happily review any patches ;) Nov 23 15:33:40 found a bug in the gio module cache script, and our poky is locked down at the moment for the mel release :P Nov 23 15:34:27 ugh, even worse than i thought. not only does it not search BBPATH, the intercept dir can't even be overridden, because it's not a varaible Nov 23 15:34:28 doh Nov 23 15:34:30 the .py hardcodes the path Nov 23 15:34:40 oh, no, i'm blind Nov 23 15:34:47 didn't I add variable for that? Nov 23 15:34:48 POSTINST_INTERCEPTS_DIR is what i needed Nov 23 15:34:58 yeah, i missed it :) Nov 23 15:35:05 iirc I had to override it even back in dizzy to fix intercepts Nov 23 15:35:09 good :) Nov 23 15:35:44 thanks :) Nov 23 15:35:50 not ideal copying the entire dir, but it'll do in a pinch Nov 23 15:36:26 I needed to get it backported 3 releases back so I went with least intrusive path :) Nov 23 15:36:36 Hmm, I could probably hack it by injecting a prefunc to do_rootfs in an extra image class to assemble an intercept dir in workdir from BBPATH and then set taht variable to it :) Nov 23 15:52:18 hmm, no way to tell at do_rootfs time which intercepts will be run, so either none of them are in file-checksums, or all of them are Nov 23 15:58:40 nice, my hack works Nov 23 16:11:50 JaMa, rburton: https://github.com/MentorEmbedded/meta-mentor/pull/900/commits/b8bce54 Nov 23 16:12:56 kergoth: nice Nov 23 16:12:58 obviously should be revamped more thoroughly upstream, but gets the job done :) Nov 23 17:23:22 hi guys, anyone knows what package installs /etc/groups? Nov 23 17:24:17 I'm getting a problem with a package, when it is been installed on a image via do_rootfs task, it complains telling that the user daemon does not exists Nov 23 17:24:56 but I have another package that runs chown daemon and it works on do_rootfs Nov 23 18:23:30 is there a syslog or something similar in poky? I'm looking at var/log and it seems to belong to root/root. So if I create a user how can I allow it to write to /var/log Nov 23 18:23:43 other than the obvious :) Nov 23 18:28:18 Strike5150: syslog is provided by busybox Nov 23 18:28:42 and there is proper syslog and rsyslog in meta-oe Nov 23 18:29:02 jama: so I just need to include syslog in my image? **** ENDING LOGGING AT Thu Nov 24 03:00:00 2016