**** BEGIN LOGGING AT Mon Feb 20 03:00:01 2017 Feb 20 08:38:59 Hi all. Quick question: Does inherit a class adds also a dependency to that particularly package? Feb 20 13:07:59 Hello everyone Feb 20 13:08:17 Hello otavio Feb 20 13:13:58 is there a way to specify a special target package repository for a .bb package? Feb 20 13:14:21 instead of just the architecture repos Feb 20 13:16:09 sandsmark: you could perhaps write a recipe that sets up the special repository, and copies packages to it from the standard rpm deploy dir Feb 20 13:16:19 hmm, yeah Feb 20 13:16:26 reading through package.bbclass now Feb 20 13:19:48 a semi-ugly hack would be to override PACKAGE_ARCH or maybe DEPLOY_DIR_* Feb 20 13:21:28 sandsmark: what is the context? Feb 20 13:21:52 well, there's a package I don't want available to our ODM yet.. Feb 20 13:22:12 so I thought I'd put it in a separate repo protected by http basic auth Feb 20 13:24:02 sandsmark: maybe the recipe shouldn't be in the tree that is used to build ODM packages in the first place Feb 20 13:24:28 yeah, it's just much more convenient than having to have a separate tree for a single package Feb 20 14:47:56 rburton: ping Feb 20 14:50:04 yo Feb 20 14:52:28 do you have some time to discuss http://lists.openembedded.org/pipermail/openembedded-core/2017-February/132810.html ? Feb 20 14:53:01 because it's a pretty important use-case for us, and maybe you have an other idea of how to cover that use-case and we have some available time to work on it... Feb 20 14:56:59 boucman_work: not sure i'm super keen on the implementation but i've not really looked closely. is there an example of how it works? Feb 20 15:00:11 no, but we can quickly cook one for you Feb 20 15:00:36 is the implementation the problem ? are you ok with the problem we are trying to solve ? Feb 20 15:00:55 because reimplementing differently is not a problem if you nudge us in the right direction Feb 20 15:03:43 rburton: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/dnf-rpm4 is ready for an AB run again, can you do that please? Feb 20 15:04:12 rburton: if that passes, then V2 of the patchset is ready for maillist review Feb 20 15:04:38 I'm running oe-selftest at the same time, so I guess it's a good point to call it a day Feb 20 15:05:04 joshuagl: "ERROR: Nothing PROVIDES 'core-image-lsb-qt3'." on the ab? recent config change problem? Feb 20 15:07:32 (RP, you also answered to the patch, so feel free to intervene) Feb 20 15:11:11 RP: can't think of an obvious recent change that might have caused that. Which AB? Feb 20 15:11:56 joshuagl: https://autobuilder.yocto.io/builders/nightly-x86-64-lsb/builds/173/steps/BuildImages/logs/stdio Feb 20 15:13:12 joshuagl, RP: same layer version problem Feb 20 15:13:21 boucman_work: "The idea here is to be able to have generic (image independant) packages, but to override the package configuration with custom ones at image-generation time." - you should be more specific than this, which are the packages that you need to modify this way? Feb 20 15:13:25 joshuagl: if self.layerversion_core > "6": Feb 20 15:13:34 thanks rburton Feb 20 15:13:35 I tend to agree with RP, don't subvert the package manager Feb 20 15:14:12 kanavin: i don't think that we are... but that's why I wanted to discuss here Feb 20 15:14:55 boucman_work: I just think that the issue needs to be solved on the recipe level Feb 20 15:15:49 so if I need to produce ten variants of a product with very slight changes to a couple of daemon's configuration Feb 20 15:16:15 I need to override (say) 10 config files, for 10 different daemons Feb 20 15:16:52 boucman_work: what are the changes? Feb 20 15:17:08 another way to look at this is you want to apply an administrators changes to your system automatically.. Feb 20 15:17:20 we use the post rootfs commands to do this BTW Feb 20 15:17:32 depends a lot on the product : network configuration (resolv.conf, /etc/network/interfaces/, hostnames, there are lots of daemons with no drop-ins support) Feb 20 15:17:50 fray: yes, that's what we do too, Feb 20 15:17:55 we've just got a small sample for our customers so they can insert a list of files to copy in 'from elsewhere', with it documented as "you should only do this for configuration files" Feb 20 15:18:06 and that's why we reactivate do_fetch, it's an awesome way to get the files we want to overaly Feb 20 15:18:11 (and yes, customers copy other things in, but we explain anything other then documentation won't be 'known' by the package manager) Feb 20 15:18:27 and since overlay is 90% of what we do, we just provide a bbclass to do that in a streamlined way Feb 20 15:18:32 ahh, we require the customers to make copies of their stuff into their own layer... so when they update their own layer that is the 'fetch' Feb 20 15:18:54 fray: yeah, we want to keep it in a separate git Feb 20 15:19:15 as long as the files being updated are tagged as 'conffiles' in the various recipes, this should work correctly for all package manager types Feb 20 15:19:45 we intend to add a QA test for the conffile aspect too, but that's a bit tricky to do, so it's not ready yet Feb 20 15:20:10 (and thx for explaining my use-case better than I did, btw :) ) Feb 20 15:20:31 makes sense.. the key thing is frame any discussion here that your purpose is to provide a way for the developer to act as an admin and configure the files.. if you frame it that way, then it avoids a lot of the pitfalls of doing something else.. Feb 20 15:21:12 (as I said, our method is -very- simple.. we add a small script that parses an xml file.. then the user provides their own xml file in their own layer with the their own config files.. but we don't actually validation the conffiles... [but should]) Feb 20 15:23:45 yeah we've been doing something similar for a dozen projects now, so it's time to streamline/upstream if possible Feb 20 15:24:51 makes sense.. like I said, frame it as an administrator configuring the system (not just randomly adding new files) and it's a good idea.. Feb 20 15:25:16 okk Feb 20 15:25:52 (I'd also love to see 'wic' updated with a configuration [copy] step... we've got projects where we have one set of packages, multiple rootfs, each with a slightly different configuration) Feb 20 15:26:03 but we can talk about that later.... Feb 20 15:27:01 kanavin: so to continue my explanation, one of the problem with a recipe-level solution is that packages are built independantly of images. So having variants of a package means building multiple (almost identical) packages and installing the right one on the right image Feb 20 15:27:41 moreover, a package can't override a file from another package, so I can't do a final "all the overrides". Feb 20 15:27:57 so a postrootfs approach seems the way to go. Feb 20 15:28:32 now, except for a few rare case, all my postroofs commands are just overriding files. Feb 20 15:29:17 So the patch is mainly about prodiving a handy way to do that : use the SRC_URI in the image recipe to easily have the overlay layout (with all the cool stuff : git, patches etc) and then apply them Feb 20 15:29:25 that's basically all there is to it Feb 20 15:32:34 boucman_work: so are you using ROOTFS_POSTPROCESS_COMMAND? Feb 20 15:34:47 kanavin: we add a task, it looked cleaner to us, but we could move to ROOTFS_POSTPROCESS_COMMAND if core-devs think it's better Feb 20 15:35:03 boucman_work: I vote for ROOTFS_POSTPROCESS_COMMAND :) Feb 20 15:35:52 the hard part is getting it to play nice with do_rm_work :P Feb 20 15:36:31 Hi, here is an example of what it should looks like user-side when using the class image_overlay in image recipe http://pastebin.com/38fCX56G Feb 20 15:38:27 This illustrate how it work at the moment without talking about implementation Feb 20 15:40:42 boucman_work: don't know about do_rm_work (never used it :), but look in classes/extrausers.bbclass, I think you can basically copy paste it Feb 20 15:41:53 will check Feb 20 15:50:04 I wonder if it will still work fine with do_fetch/do_unpack (after a change in the recipe I mean) if we use ROOTFS_POSTPROCESS_COMMAND instead of a task depending on it ? Beside the major problem with do_rm_work was it delete stamps of do_fetch/do_unpack causing the task do_install_overlay to reexecute and do_image to fail because do_rootfs didn't. I will check if that work. Feb 20 15:52:50 geoffrey_l: when you use ROOTFS_POSTPROCESS_COMMAND, you don't fetch some external zip file at all, you provide the necessary settings through a variable setting in your image configuration Feb 20 15:54:08 geoffrey_l: again, look how extrausers.bbclass does it Feb 20 15:55:07 kanavin: So it means there is no way to use the do_fetch capabilities (like git/remote files/...) with ROOTFS_POSTPROCESS_COMMAND ? :/ Feb 20 15:55:26 geoffrey_l: nope, but you can do ad hoc fetching of course Feb 20 15:55:46 there's no reason you couldn't keep fetch/unpack in an image recipe if you work around its issues Feb 20 16:10:53 hi Guys Feb 20 16:12:41 I'm attempting to compile a yocto with genivi and I'm having an issue with a recipe failing on a deprecation warning (gcc) . I've attempted to add flags to the bitbake.conf to ignore this warning globally, but it's not making any difference. Feb 20 16:13:23 aatchison: you may want to ask in #automotive Feb 20 16:13:39 that's the upstream channel for genivi Feb 20 16:13:58 thanks so much! Feb 20 16:14:26 & AGL :) Feb 20 16:24:39 to solve aatchison's issue, is there a yocto-way to tell all recipes to use a self-built gcc? Feb 20 16:27:49 you mean build a gcc-native? Feb 20 16:28:11 you can tell it to use a different compiler to 'gcc' Feb 20 16:28:42 easier fix is to set BUILD_CFLAGS etc to pass the right flags so that the host gcc doesn't error out Feb 20 16:34:59 rburton: ah ok, thanks Feb 20 16:41:44 kanavin: https://autobuilder.yoctoproject.org/main/builders/nightly-x86-lsb/builds/1069 Feb 20 16:41:59 oh thats not right Feb 20 16:42:03 https://autobuilder.yoctoproject.org/main/builders/nightly-x86-lsb/builds/1070 Feb 20 16:42:08 didn't mean to fire it on -lsb Feb 20 16:51:46 rburton: http://pastebin.com/sqX55DXb <= what's usually needed to use gcc-5 Feb 20 16:55:25 building elphel is fun. 20mb error log. the only error message: "Error 2" Feb 20 16:56:40 Anyone able to give me a bit of advice on touchscreen integration? http://pastebin.com/u7s8vHtx Feb 20 16:57:24 I can see the device in lsusb, and there's some error messages in dmesg, but I see nothing related to the device in /proc/bus/input/devices Feb 20 16:57:34 Thanks rburton. I did try to set BUILD_CFLAGS in the bitbake.conf but it seemed to have no effect Feb 20 16:58:17 any advice for troubleshooting this issue is appreciated Feb 20 17:02:18 actually... I used TARGET_CFLAGS , so of course that didn't work :D Feb 20 17:46:13 has anyone tested update-engine to handle upgrades? Feb 20 17:47:22 no. looks like it does a lot of what recipe reporting service does Feb 20 17:49:23 I mean on a device Feb 20 18:27:41 hello Feb 20 18:28:31 I wanted to ask, what is the best way to install a python script on systemd using bitbake Feb 20 18:28:53 i got most of the bb file but idk what will be the easiest way to install it Feb 20 19:33:37 rburton: thanks, looks like v2 isn't happening just yet :( Feb 20 19:33:45 I did fix all the review concerns though Feb 20 20:36:46 Does anyone know what: "W: GPG error: http://192.168.7.1 stable InRelease: Could not execute 'gpgv' to verify signature (is gpgv installed?)" means? I have gpgv installed. Feb 20 21:22:50 rburton: and once more please, it was missing entries in security_flags Feb 20 22:04:44 recipe A depends on recipe B-native as it runs a program from it. Recipe B-native requires that files from C-native are installed so B-native's executables can run. What's the right way to communicate that? Adding DEPENDS="C-native" to B-native.bb doesn't appear sufficient: when building A, C-native's files aren't in the recipe sysroot. Do RDEPENDS affect this? (didn't think they did anything for -native). Feb 20 22:23:55 Looks like folks on the mailing list are having the same issue: http://lists.openembedded.org/pipermail/openembedded-core/2017-February/132608.html . Adding all transative native runtime dependencies to recipies or using a class-per native dependency doesn't seem like a real solution here. Seems like either packaging needs to happen so RDEPENDS can be populated, or transative DEPENDS need to be included in RSS Feb 20 22:23:57 (which pretty much defeats the purpose of RSS). Feb 20 22:24:30 kanavin_home: fired x86-64, still pending a worker Feb 20 22:52:23 Anyone know why apt-key on my yocto based build doesn't *do* anything? Literally, the executable loads, waits for a second or two, and then stops. On my ubuntu machine, a naked apt-get at least gets me a usage message, but not in yocto. Feb 20 22:52:49 Is there a reason, did yocto create their own apt-key source? Feb 20 22:53:17 no that should be the same source Feb 20 22:53:21 strace it to see what it does? Feb 20 22:57:32 Ok, let me add strace to my build. Feb 20 23:14:28 huh. what does [[ ]] do in a sed regex Feb 20 23:17:42 rburton: heh, i think it [[] is a one symbol class (any of "["), and then last ] is a literal ]. so result is same as \[\] Feb 20 23:18:05 well, there's whitespace between so [, space, tab, ] Feb 20 23:18:12 ah, yeah Feb 20 23:18:17 but that makes literally no sense in the context of what its trying to do Feb 20 23:19:22 @rburton I'm getting an error code of 127. Which is SIGCHLD Feb 20 23:19:37 But I cannot figure out which command it is trying to run. Feb 20 23:19:40 spierepf: strace into children to find out what the child is up to Feb 20 23:19:43 (-ff) Feb 20 23:24:06 gpg? why does apt-key want to run gpg? Feb 20 23:24:29 Ok, how do I get both gpg and gpgv on the same yocto? Feb 20 23:26:56 My understanding is that gpg (which apt-key wants to use) is provided by gnupg version 2.1.14 and gpgv (which apt-get wants to use) is provided by gnupg version 1.4.7 Feb 20 23:28:35 Or am I reading this wrong? http://lists.openembedded.org/pipermail/openembedded-core/2016-December/129764.html Feb 20 23:41:35 @rburton I moved to 2.1.11 of gnupg and it worked! Thanks so much for your help! Feb 20 23:59:54 argh, regex head isn't working Feb 21 00:00:14 if i have 'gcc-arm -foo -bar', i want to sed it and end up with '-foo -bar' Feb 21 00:01:37 okay, made a big assumption and cheated Feb 21 01:53:51 I've got yocto building and baking up debian packages. I've got a script that takes the contents of poky/build/tmp/deploy/deb and produces a debian package repository ala https://wiki.debian.org/SettingUpSignedAptRepositoryWithReprepro and now for the fun part. Is there a way to convince bitbake to build a .deb package without necessarily installing it directly onto the filesystem image? Feb 21 01:55:27 I figure there are dozens of packages that I'd like in my repo, but which aren't always necessary to have on a deployed system. Debug tools for example. Don't always want them around, but sometimes they are useful, and it would be super cool if they were an apt-get install away. Feb 21 02:08:02 you can always do "bitbake foo" even if foo isn't listed to be a part of your deployed rootfs. Feb 21 02:11:00 paulg and that won't install foo on my rootfs image? Feb 21 02:11:36 nope ; just creates the package. Feb 21 02:11:52 Wicked. I'll give that a try. Thanks! Feb 21 02:12:04 no problem. **** ENDING LOGGING AT Tue Feb 21 03:00:00 2017