**** BEGIN LOGGING AT Tue Mar 29 02:59:58 2016 Mar 29 07:27:42 Hi all. I'm having issues with a patch from patchwork. I never did patching stuff before and i can't get it working: https://gist.github.com/Anticom/b9c258f3d7fcc97be07b Mar 29 07:28:04 I've read "12.2.2. Applying Patches" in the manual but it isn't verry verbose either Mar 29 07:28:24 So how would working with patchwork patches work? Mar 29 07:28:57 do i have to place the path in layer/recipes-xy/package/files ? Mar 29 07:32:43 Anticom: you apply them in layer they are for Mar 29 07:33:16 JaMa: The question i'm having is "how" ? Mar 29 07:33:29 I never did this before and as i said i just get that error and dunno what's wrong Mar 29 07:38:19 Anticom: well applying a patch basically should be nothing more than adding the file with the .patch ending to SRC_URI Mar 29 07:38:23 Anticom: download mbox format and appy it with "git am" Mar 29 07:38:50 if you have more of them, prefix them with 0001, 0002, to get a consistant application order. Mar 29 07:42:17 This is my bbappend: https://gist.github.com/Anticom/eaf6d39f8902e192d9e0 Mar 29 07:43:13 So basically i just did append it to SRC_URI but it still isn't working Mar 29 07:43:38 does the patch have to be in the same dir as the bbappend? Because it is right now for me Mar 29 07:45:26 Anticom: that patch is for oe-core repo, you should apply it there Mar 29 07:46:07 it's not patch for init-ifupdown source as your bbappend is trying to use it Mar 29 07:46:27 How can i tell it to apply "somewhere" ? Mar 29 07:47:14 So the patches in patchwork are not meant to be used in a recipe but applied manually instead? Is that what you're telling me? Mar 29 07:48:35 Anticom: nope, the base problem is that a patch is not something free standing, its something that relates to a specific state of source Mar 29 07:49:08 Anticom: and the patch process in a recipe relates to the state of the package source - not the state of the layer source. Mar 29 07:49:45 LetoThe2nd: So how would i apply that patch correctly then? Mar 29 07:49:53 And **where** Mar 29 07:50:29 Anticom: it looks like it would have to be applies to poky itself Mar 29 07:51:16 LetoThe2nd: But poky isn't versioned by us. Should it usually be? I thought that you shouldn't overwrite existing sources directly but rather use .bbappend's Mar 29 07:51:18 etc. Mar 29 07:51:38 Anticom: no, but you're starting to see the point. this patch just isn't what you expected. Mar 29 07:51:52 Anticom: this patch is probably meant for inclusing into poky upstream. Mar 29 07:52:15 So after all it is not meant to be used in a recipe indeed? Mar 29 07:52:21 Anticom: bingo. Mar 29 07:52:30 That's what i've been asking before :p Mar 29 07:52:59 Anticom: nope, you asked how applying a patch works Mar 29 07:53:16 Okay so different approach: We got ifupdown working with sysvinit. Wouldn't it be sufficient to grab a systemd service generated by systemd-sysv-generator and install that one? Mar 29 07:53:44 [09:47] So the patches in patchwork are not meant to be used in a recipe but applied manually instead? Is that what you're telling me? Mar 29 07:54:22 Anticom: 'patchwork' is not something that is specfic to a project, hence this part of the question didn't make sense anyways. Mar 29 07:54:39 Doesn't matter now anyway since i can't really use it Mar 29 07:54:41 :) Mar 29 07:55:33 Anticom: well if it does something you want, you can always extract the needed bits and pieces, and then pour it into whatever state you need. Mar 29 07:56:01 Well it still does matter because i've learned something but i'd like to move forward now. I'm still not quite sure how this 'VIRTUAL-RUNTIME_initscripts = ""' works exactly Mar 29 07:56:25 Iirc there wasn't any /etc/network/interfaces in my systemd build anymore Mar 29 07:57:26 And i dunno, whether the init.d/networking was still there Mar 29 07:57:41 how does bitbake decide what init scripts to exclude and which to keep? Mar 29 07:58:21 Or is it simply, that "our" custom init scripts wheren't installed via the VIRTUAL-RUNTIME_initscripts ? Mar 29 08:00:44 according to bitbake -e VIRTUAL-RUNTIME_initscripts is only set in my local.conf (to ""). So where's the rest comming from? Mar 29 08:56:49 Anticom: if there is a file in the image, that you believe should not be there, you can run oe-pkgdata-util find-path to find pacakge that brought that file in Mar 29 08:57:25 all files (with some exception) should be accounted for Mar 29 08:57:34 okay cheers Mar 29 08:58:54 One more thing about systemd... someone said conman was the default choice when using systemd. However i can't find anything related to conman in systemd.bb, neither in package_config nor in dependencies http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/recipes-core/systemd/systemd_225.bb?h=jethro Mar 29 08:59:23 Anticom: in what context did "someone" say that ? Mar 29 08:59:55 think rburton was telling me that a few days or weeks ago Mar 29 09:00:04 (yocto would need something similar to how we choose our init system for network management, I think...) Mar 29 09:01:36 boucman_work: http://cdn.meme.am/instances/27383909.jpg Mar 29 09:05:21 Anticom: i doubt that there is any default ;) Mar 29 09:05:46 iirc connman was indeed automatically installed, when not using netword explicitly Mar 29 09:05:58 building a fresh systemd based image Mar 29 09:06:04 have to take a closer look again Mar 29 09:12:43 that's weird, connman uses a really awkward interface management policy and unfortunately has horrible dbus interface Mar 29 09:24:06 When working on a bbappend how is "inherit" handled? supposing the bb has "inerhit a" how would i add 'b' to inherit in my bbappend? --> "inherit a b" or is "inerhit b" sufficient? Mar 29 09:25:25 inhertib Mar 29 09:25:30 inherit b Mar 29 09:27:28 kergoth: I can't see the behaviour being documented here https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#inherit-directive *hint* Mar 29 10:01:53 How do I install package manager in target? Mar 29 10:02:11 Which local.conf variable shall I use? Mar 29 10:02:34 rtrt: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#using-runtime-package-management Mar 29 10:12:47 @LetoThe2nd Thankyou Mar 29 11:05:47 Btw how do you handle installing additional packages for debugging but leaving them out in a production build LetoThe2nd ? Mar 29 11:06:31 Our current layer is a mess and i'm currently fixing it as good as i can. However i couldn't find any best practices on that topic yet Mar 29 11:06:59 Anticom: well we have xyz-image-dev and xyz-image Mar 29 11:07:15 where xyz-image-dev is basically xyz-image + funky dev stuff Mar 29 11:07:24 LetoThe2nd: Okay so you control that on an image basis not via some var (?) Mar 29 11:07:50 Anticom: every dev is free to do as he/she wants, but usually its on image basis, yes. Mar 29 11:08:24 I have 2 bitbake files with same versions in different layers. How do I know which one is being considered for build? Mar 29 11:08:40 rtrt: what do you mean with "bitbake file" ? Mar 29 11:08:46 bb / bbclass / bbappend Mar 29 11:08:47 ? Mar 29 11:09:29 @Anticom recipes Mar 29 11:09:37 bb file Mar 29 11:09:51 rtrt: usually that depends on your layer priority. See http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#managing-layers Mar 29 11:10:19 rtrt: You can also do 'bitbake -e | less' and search for the recipe there to find out more Mar 29 11:10:54 rtrt: Oh and FYI: a .bb file is usually refered to as recipe afaik :) Mar 29 11:14:02 @Anticom Thanks :) . bitbake-layers show-layers is giving out layer priority. Will that number suffice for me to decide which layer's recipe is being used? Mar 29 11:14:48 rtrt: well as far as i understood it, if you've got the same recipe in multiple layers the layer with the highest priority usually wins Mar 29 11:15:27 rtrt: try 'bitbake-layers show-overlayed' to see whether there are some overlays Mar 29 11:16:06 Ok Mar 29 11:16:09 btw if one of those recipes is your own you should consider using a .bbappend to only modify what you want to modify instead of overwriting the entire recipe Mar 29 11:16:39 just copying a .bb to your own layer and modifying it there is considered bad practise Mar 29 11:17:22 +1 for LetoThe2nd -dev{el} image, i usually include extra tools that are not needed in target images, setup local package feeds and add debug-tweaks to IMAGE_FEATURES Mar 29 11:29:48 @Anticom Yeah. I'm not writing any recipes. I've systemd_219.bb from both poky/meta and openembedded-core/meta Mar 29 11:29:57 btw why is init-ifupdown in recipes-core and not in recipes-connectivity ? Mar 29 11:30:03 I'm trying to findout which one is being used in the build Mar 29 11:36:09 rtrt: poky/meta == oe-core/meta you shouldn't be including both Mar 29 11:37:28 hi i am using this in my recipe do_install mkdir -p ${base_libdir} mkdir -p ${base_libdir}/optee_armtz Mar 29 11:37:36 @JaMa Does poky have everything that is there in openembedded-core? Mar 29 11:38:04 but getting an error saying can not create directory permission denied Mar 29 11:40:04 @niteshnarayanlal Did you try install -d as well? Mar 29 11:41:45 rtrt: yes, poky is just repository which combines 3 other repositories into one Mar 29 11:42:47 rtrt, you mean I should something like ${D}${base_libdir}? Mar 29 11:45:42 ah it has to be ${D}{$base_libdir} Mar 29 11:45:43 :) Mar 29 11:46:29 Do I need to add base_libdir in FILES_${PN} += "${base_libdir}/optee_armtz " or just FILES_${PN} += "optee_armtz " Mar 29 12:00:01 I want to use systemd. systemd requires many kernel config options. Are those kernel options enabled automatically in Yocto already? Mar 29 12:01:49 doyu: in some way or another, yes, since systemd works out of the box for me... Mar 29 12:03:23 boucman_work: that's quite good news for me. does this mean that there's some kind of systemd.scc in kernel extra repo? I'm looking into extra repo now.... Mar 29 12:04:06 doyu: Since it's a distro feature and not simply "just" a recipe it takes care of more things like for example kernel config >>> http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-DISTRO_FEATURES Mar 29 12:14:09 Anticom: yes, it's not just about kernel, but current my concern is that, I don't want to tweak our bsp kernel config for systemd. actually kernel-cache repo has systemd.{cfg,scc} but it only has FHANDLE. this doesn't meet the all systemd requirements :( Mar 29 12:14:49 systemd requires huge kernel configs, https://github.com/systemd/systemd/blob/master/README#L37 Mar 29 12:16:59 doyu: what bsp is that ? Mar 29 12:17:59 boucman_work: their own i suppose Mar 29 12:18:43 I mean who's the maker, did they provide a proper yocto recipe or is it a precompiled sdk, Mar 29 12:18:49 what's your situation :P Mar 29 12:19:33 doyu: How about SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES','systemd','the-patch-to-add.patch','',d)}" to add patches depending on whether systemd is in your distro features or not Mar 29 12:19:58 that way you can control which additional patches will be applied, if you've got systemd as distro feature + init manager in your local.conf Mar 29 12:20:02 should work that way IMO Mar 29 12:20:04 but not sure Mar 29 12:20:06 never did it myself Mar 29 12:22:24 Anticom: adding/removing stuff to kernel is a bit special Mar 29 12:22:51 and since doyu didn't tell us yet if he uses a precompiled kernel or not, I'm not sure what the right way to do what he wants Mar 29 12:23:15 Anticom: I think that systemd kernel config requirements is so general. Those kernel config should be enabled automatically by dependency in the standard. I don't want to tweak my bsp for this systemd standard. Mar 29 12:24:00 Hm well then i can't help you i'm afraid Mar 29 12:24:14 boucman_work: IMHO, either way should work. So I'm considering to add the rest of kernel config in systemd.cfg in kernel cache repo. Mar 29 12:27:21 doyu: in theory it should work out of the box, knowing how yocto deals with that sort of stuff... in practice BSP developers tend to hack board-specific stuff in weird ways, so the best thing to do is to build the kernel and see what happens Mar 29 12:31:45 boucman_work: it's better to check with systemd enabled. There mgiht be some magic happeing to enable the rest....thx! Mar 29 12:44:09 does anyone know ppc64 qemu support status? ppc64 isn't listed in "meta/conf/machine". Mar 29 13:23:22 hello Mar 29 13:24:05 is there a way to convert a str from a getVar call to package_data?! Mar 29 13:24:18 in classes?! Mar 29 14:00:59 Heya, whats the formal way to add configfs to mtab (/proc/mounts) under yocto? Mar 29 14:14:14 hi! is there any way to have a bbclassappend like method? i don't want to touch all recipe in the build Mar 29 14:15:29 i dont think so, but you can override a class in your own layer Mar 29 14:16:01 adrians Mar 29 14:20:40 thanks fl0v0 Mar 29 14:21:01 the ideea was to imact the setup as little as possible Mar 29 14:21:58 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch is broken. All EM_X86_64 files should also have FLAG_ELF_LIB6. Mar 29 14:22:02 See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/i386/readelflib.c;h=58872102c2e187b5375b75b8da0241578a39e9ea;hb=HEAD#l39 Mar 29 16:41:52 can anyone explain why startup.nsh is only emitted for iso and not non-iso efi images? you still want an automated boot on efi systems regardless of whther it's an iso or not.. Mar 29 16:42:56 and mkefiboot writes it out regardless.. Mar 29 16:45:20 ah, i see Mar 29 16:45:30 hmm Mar 29 16:46:58 * kergoth scratches head Mar 29 16:56:30 i still don't see why it's missing there, but it wouldn't help the issue i'm having anyway Mar 29 16:57:24 I'm assuming no one else has run into the issue where there's no startup.nsh for wic generated efi images? I'm sick of typing in the boot command manually Mar 29 17:25:34 Hmm, it's occasionally handy to install remake on the host and set MAKE_pn-foo = "remake" Mar 29 17:43:34 Hi all, does anyone have a suggestion on what how to generate an image that installs a package to an external filesystem (not the rootfs)? Mar 29 18:54:59 Who maintains linux-yocto-4.4? Mar 29 19:02:08 ulf`: zedd_ Mar 29 20:11:01 gah, my cache partition with my downloads and sstate is out of space, 100gb total, and that's after pruning sstate from >1wk ago. Mar 29 20:11:02 * kergoth grumbles Mar 29 20:34:27 kergoth: I've been trying to reduce the cache size, I'd welcome any help! :) Mar 29 20:35:01 it's non-trivial, and in this case i'm doing world builds and comparing buildhistory, changing a core class, which results in dirtying almost my entire cache :) Mar 29 20:35:03 nature of the beast Mar 29 21:08:18 This may be a silly question, but with master branch oe-core and bitbake, if I just set up an initial project and "bitbake -p core-image-minimal", I get a very strange failure trying to expand an anonymous python function in base.bbclass. Mar 29 21:08:29 Ultimately, "Fetcher failure: SRCREV was used yet no valid SCM was found in SRC_URI". Mar 29 21:08:56 And this seems weird enough that I'm curious as to whether other people are seeing it also, in case it's somehow My Fault. Mar 29 21:23:11 huh. apparently i had bitbake checked out to version 1.28 for reasons unknown to me. Mar 29 21:24:51 ... that's weird, because the failure was originally happening in a directory where I'm pretty sure it should have been checked out on master, but it did not do what I expected. Well, anyway, problem solved, solution is use same branch for oe-core and bitbake. **** ENDING LOGGING AT Wed Mar 30 02:59:58 2016