**** BEGIN LOGGING AT Mon Apr 23 03:00:12 2018 Apr 23 04:40:29 2~2~ Apr 23 07:17:29 how to add source file to image recipe? I want to check that some files exists on target image as ROOTFS_POSTPROCESS_COMMAND but I need the reference as source file for each image. Apr 23 07:24:59 mcfrisk: in do_install_append, add source in deploy dir install ${S}/stuff.c ${D}/${datadir}/stuff.c , then FILES_${PN}-dev += "${datadir}/stuff.c" Apr 23 07:37:51 nayfe: I don't want to install files to the image. I want to check after do_rootfs that certain files exists in image. These certain files are a list of files and metadata that I would like to refer within do_rootfs. Adding SRC_URI and a file://my_file_list.txt doesn't work. The SRC_URI files are not addressable at image recipe build time... Apr 23 07:43:30 New news from stackoverflow: How to port grpc helloworld(CPP) example on yocto Apr 23 07:50:34 mcfrisk maybe you can look at sanity.bbclass & utility-tasks.bbclass for examples Apr 23 08:09:09 nayfe: those classes do check rootfs files but not against input data.. image bbclass doesn't derive from base so fetch and unpack aren't available.. Apr 23 08:43:20 Hi, folks! Apr 23 08:44:18 I know about this syntax to run bitbake "DISTRO=mydistro bitbake my-image-minimal" Apr 23 08:44:46 can I pass more than one variable like DISTRO and how? Apr 23 08:45:20 AFAIK you can have multiple recipes to build and even multiple package managers being fed, but MACHINE and DISTRO are singular. Apr 23 08:47:16 LetoThe2nd: you mean i can't do smth like that:"MACHINE=mymachine DISTRO=mydistro bitbake my-image-minimal"? Apr 23 08:50:56 you can do that, but there is only one value for DISTRO and MACHINE Apr 23 08:51:43 there has been some work on multimachine, but i don't think its worth recommending: http://lists.openembedded.org/pipermail/bitbake-devel/2016-June/007557.html Apr 23 08:53:58 LetoThe2nd: ok. thanks Apr 23 08:54:39 LetoThe2nd: i asked just about setting of variables. Not about multimachines Apr 23 08:55:09 acrap: ah, the question was about more distinct variables? sure, no problem at all. Apr 23 08:56:02 basically anything in BB_ENV_WHITELIST is allowed: https://www.yoctoproject.org/docs/2.4.2/bitbake-user-manual/bitbake-user-manual.html#var-BB_ENV_WHITELIST Apr 23 08:57:38 why doesn't image.bbclass import base.bbclass? Apr 23 08:58:51 LetoThe2nd: by the way. Syntax what I showed before doesn't work for me. DISTRO part does work, but machine doesn't Apr 23 08:59:25 MACHINE=qemux86 DISTRO=mydistro-cgl bitbake my-image-cgl Apr 23 08:59:28 acrap: then look at your local.conf, probably you're assigning MACHINE by '=', and DISTRO by '?=' Apr 23 08:59:51 MACHINE assigned with ??= Apr 23 09:00:13 '=' means "always assing", '?=' means "only assign if not set already, like with the env" Apr 23 09:00:22 then i'm pretty sure you reversed your last post. Apr 23 09:01:16 here, see https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#variable-expansion Apr 23 09:01:18 i found the error Apr 23 09:01:23 (3.1.3, 3.1.4, 3.1.5) Apr 23 09:01:55 MACHINE was also assigned in layer.conf with "=" Apr 23 09:02:06 LetoThe2nd: thanks for the support Apr 23 09:02:51 LetoThe2nd: I very appreciate that Yocto community is so friendly and helpful. Apr 23 09:03:09 now i'm sad. Apr 23 09:03:32 seems like i totally failed to live up to my grumpy old guy image. :-( Apr 23 09:05:07 LetoThe2nd: my English is not so strong to detect sarcasm Apr 23 09:05:34 acrap: all is well, no worries Apr 23 09:38:37 Hello, i'm trying to make my own class (.bbclass) file to generate an custom image for me. (Custom partition layout, but including efi boot loader) But where can i find more information about all the variables and stuff that i can use in a class file ? And also some basic information about how to write a class from the very start ? Apr 23 09:47:24 osten: whatyou can use inside a class is actually not different from what you can use in a recipe, AFAIK Apr 23 09:48:30 osten: here is the official (albeit short) explanation as well as a lot of examples: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-classes Apr 23 09:49:33 osten: in fact, i'd actually say that a bbclass is jsut "an include file that you can reach from anywhere" Apr 23 09:50:06 effectively that's close enough :) Apr 23 09:50:19 osten: have you looked at wic for custom partition layouts? Apr 23 09:50:25 rburton: i'm sure there's a handful of corner cases :) Apr 23 09:50:52 LetoThe2nd: Thanks, that's probably a good way to see it :) Apr 23 09:52:10 rburton: i want to add some specific files when i do the partitions, as for example all my applications should be moved to the right partition. The reason behind this is because i want to use rauc as update system. With an a+b update structure for my applications. Apr 23 10:15:48 should both syslogd.service and busybox-syslog.service be running on a system? I have two syslogd running. Apr 23 10:18:47 tasslehoff_ do you know which package is providing syslogd.service? Apr 23 10:20:39 paulbarker: which package puts it into the image, you mean? Apr 23 10:21:04 yes Apr 23 10:21:22 paulbarker: searching now. might take a while Apr 23 10:21:44 Ok. Which branch of yocto project are you using? Apr 23 10:21:49 pyro Apr 23 10:22:41 * paulbarker looks at pyro Apr 23 10:22:42 paulbarker: seems to be sysklogd Apr 23 10:22:54 I have two of those as well :) Apr 23 10:23:02 sysklogd and busybox-klogd Apr 23 10:23:51 You may want to try backporting http://git.openembedded.org/openembedded-core/commit/meta/recipes-core/busybox/busybox.inc?id=597bbf99ee8e88294f2ed96c84a51f9ed83e8933 Apr 23 10:24:28 Or at least using a bbappend to set RCONFLICTS_busybox-syslog Apr 23 10:25:28 paulbarker: ooh. highly relevant. thanks! Apr 23 10:26:20 I'd recommend taking a look at busybox.inc to see what gets packaged and how it gets pulled in as an RRECOMMENDS Apr 23 10:28:26 You could also try adding busybox-syslog to BAD_RECOMMENDATIONS (https://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#var-BAD_RECOMMENDATIONS) if you want to make sure you get the sysklogd version Apr 23 10:30:26 paulbarker: yeah. I just wondered which one I actually want :) Apr 23 10:31:31 Pick one and see if anything breaks :p Apr 23 10:31:54 paulbarker: my thought exactly. thanks :) Apr 23 10:32:27 The scream test strikes again Apr 23 11:01:00 I can't access to Yocto manual from Russia without VPN O_o Apr 23 11:08:06 acrap: does your ISP maybe do some fancy filtering? Apr 23 11:09:26 paulbarker: nothing broke. I lost /var/log/messages, but I don't miss it :) Apr 23 11:10:44 LetoThe2nd: I've never seen this issue before... Looks like our censorship blocks Yocto resources accidentally. Apr 23 11:14:43 I share this issue through Twitter and mentioned Roscomnadzor (our censorship bureau). But I am not sure they going to fix it. They are too busy with their process of blocking Telegram now. Apr 23 11:40:19 paulbarker: it's my adding of packagegroup-core-full-cmdline that causes ksyslogd to enter the image Apr 23 12:20:59 I have a recipe that depens on proj being installed in the image as well. What is the proper way to add it? Apr 23 12:21:31 RDEPENDS_${PN} was seemingly not the way to go Apr 23 12:27:39 yes, RDEPENDS is exactly what you want Apr 23 12:32:14 rburton: hm. perhaps all the packages were already in my image then, since the manifest did not change. Apr 23 12:32:28 or, you didn't actually install PN Apr 23 12:32:30 but yes, both possible Apr 23 12:33:49 they were already in the manifest, but I was missing proj-dev, instead of proj. Apr 23 12:35:18 a runtime package depending on a -dev is pretty unusual Apr 23 12:35:58 rburton: yeah. investigating that now. seems maybe proj doesn't give me libproj.so in my image Apr 23 12:36:37 if the .so is what you actually need and not a development-only symlink then fix the packaging Apr 23 12:36:59 assumption is that .so is a development-only unversioned symlink to the versioned library in PN Apr 23 12:37:03 if thats not true, change the packaging Apr 23 12:39:37 rburton: libproj.so.0 and its target is indeed in the image, so I think proj behaves well. Apr 23 12:40:06 will have to see what gdal is doing. Apr 23 13:24:06 hi all Apr 23 13:24:23 I'm trying to build a gtk3 application in yocto Apr 23 13:25:11 I configured eclipse and the hello world prog is ok in the remote machine Apr 23 13:25:24 but I can't figure it out how to add library to project Apr 23 13:25:31 someone can help me? Apr 23 13:27:02 daniele_d: you mean you are missing the library on the target? Apr 23 13:27:29 yes Apr 23 13:27:39 gtk/gtk.h is missing Apr 23 13:28:03 and you aretrying to compile *IN* the target? why that? Apr 23 13:28:29 I use ecplise as decribed Apr 23 13:28:45 But I don't know how can I compile and then move to the target Apr 23 13:29:02 i mean, usually you would have your application recipe DEPEND on all your libs, and thats it. during dev time, you would add all needed libraries/dependencies to the image, then build image, build sdk, and use that sdk to cross compile Apr 23 13:29:52 so after i install the toolchain I need to create a recipe and bitbake my c prog against it? Apr 23 13:30:12 install which toolchain? Apr 23 13:30:34 i use a terminal in which I installed yocto Apr 23 13:30:35 the steps are: 1) create an image that has all the libraries you need. build that. Apr 23 13:30:47 ok Apr 23 13:31:02 2) create a sdk that fits the image. its basically just bitbake -c populate_sdk $YOURFUNNYIMAGE Apr 23 13:31:13 3) use that sdk for cross compiling Apr 23 13:31:23 ok I'll try Apr 23 13:31:53 its all neatly laid out here: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#sdk-using-the-standard-sdk Apr 23 13:32:09 LetoThe2nd: very well explained :-D Apr 23 13:33:09 but it will work in my environment? I have a variscite product Apr 23 13:33:26 daniele_d: Yocto is platform independent Apr 23 13:33:38 its the generic yocto/openembedded way. Apr 23 13:33:43 ok Apr 23 13:34:44 so I nedd to check all library for my peripherals are installed Apr 23 13:35:03 as long as you don't have a recipe for your application, yes. Apr 23 13:35:35 you can also first create a dummy recipe for your application which does not yet install anything of its own, but already pull in the dependencies Apr 23 13:40:23 if I add libgtk-3-dev to local-conf bitbake gives me error Apr 23 13:40:39 where can I found syntax for the packages? Apr 23 13:41:51 excuse me my error... missin \ Apr 23 13:44:48 New news from stackoverflow: OTA update with SWupdate in yocto [closed] Apr 23 14:11:54 hello guys, I'm adding vsftpd to my yocto image. The install task of vsftpd needs to be customized installing some files. Among them I need to add a file called pam_pwdfile.so. pam_pwd_file.so is a symbolink link to pam_pwdfile.so.1.0.0. in particulare pam_pwdfile.so is provided by libapm-pwdfile-dev and pam_pwdfile.so.1.0.0 by libpam-pwdfile. Both packages Are correctly generated by a custom recipe called libpam-pwdfile. So in my Apr 23 14:11:54 vsftpd_%.bbappend I have added RDEPENDS_${PN} += "libpam-pwdfile libpam-pwdfile-dev". If I run "bitbake vsftpd" I get the following error: do_package_qa: QA Issue: vsftpd rdepends on libpam-pwdfile-dev [dev-deps] Apr 23 14:11:59 how can I fix it ? Apr 23 14:27:00 fberg: You shouldn't need the -dev package at runtime (via RDEPENDS), only build time (via DEPENDS). Apr 23 14:27:28 DEPENDS += "libpam-pwdfile" should be sufficent Apr 23 14:28:27 JPEW: Maybe I'm wong but as far as I know I need the libpam-pwdfile.so at runtime Apr 23 14:28:55 and this file is shipped with libpam-pwdfile-dev package Apr 23 14:29:40 *pam_pwdfile.so Apr 23 14:29:53 fberg: Usually at "runtime" you link against a versioned library. The unversioned library is only for deveopment Apr 23 14:30:14 fberg: then the libpam-pwdfile package is broken Apr 23 14:30:28 yes, in fact pam_wpdfile.so is a symbolic link Apr 23 14:30:50 oh its even more broken Apr 23 14:31:10 the versioned library is pam_pwdfile.so.1.0.0 shipped with libam-pwdfile package Apr 23 14:31:32 rbuton: :o Apr 23 14:31:42 PAM modules are in /lib/security/libpam_*.so Apr 23 14:31:56 thats a real file, not a symlink, and there should not be symlinks Apr 23 14:32:04 its not a library, it's a module Apr 23 14:32:31 assuming this is the makefile, it does the right thing: https://github.com/tiwe-de/libpam-pwdfile/blob/master/Makefile Apr 23 14:33:13 let me explain. I need to use vsftpd with virtual users. To enable virtual user I must have the pam_pwdfile.so. Since ther is no any out of the box recipe that ship pam_pwdifle.so, I have created one Apr 23 14:34:05 https://pastebin.com/WtSdXdh1 Apr 23 14:34:24 where to start Apr 23 14:34:29 line 5, no PR required Apr 23 14:34:39 line 7, don't use /archive/ links as they'll change Apr 23 14:34:58 line 15, name the recipe correctly and you can remove Apr 23 14:35:17 line 18 onwards, why are you inventing versions? Apr 23 14:36:12 it comes with a makefile which does the right thing. just have a do_install that does 'oe_runmake DESTDIR='${D}' install' Apr 23 14:36:25 rburton: I have named it 1.0.0 since tha erchive referes to the 1.0.0 tag Apr 23 14:36:32 fberg: that's not what library versions are Apr 23 14:36:47 the question you should be asking is "why doesn't the makefile do this" Apr 23 14:36:58 https://github.com/tiwe-de/libpam-pwdfile/blob/master/Makefile#L29 Apr 23 14:37:25 the answer is because PAM modules are not libraries, they're modules. they don't get versioned. Apr 23 14:37:38 there's no development package for a module because you can't link to a module Apr 23 14:37:50 rburton: please be gentle with me. I'm not a software developer :) Apr 23 14:37:52 just put $base_libdir/security into FILES_PN and you're done Apr 23 14:38:37 to expand on the /archive/ thing, those tarballs are generated on demand by github. it's very annoying when the day after you ship something the tarball regenerates and your checksums are wrong. Apr 23 14:38:38 rburton: thanks, so I will remove the version number and use oe_runmake DESTDIR='${D}' install Apr 23 14:39:24 this package doesn't have proper tarballs so best practise is to do a git fetch Apr 23 14:39:27 ok, I will remove the archive SRC Apr 23 14:39:33 thanks ! Apr 23 14:47:31 thanks for now and bye! Apr 23 14:53:43 Hi, does DEPENDS also affect TARGET_CFLAGS ? for example I want to add DEPENDS = "glib-2.0", so that I can include glib.h in a application, but I dont see the CFLAGS appended am I missing something ? Apr 23 14:55:07 prabhakarlad: nope, that are two independent thngs. Apr 23 14:55:25 prabhakarlad: DEPENDS tells bitbake that it has to make sure everything is in place. Apr 23 14:55:53 prabhakarlad: the actual generation of flags etc is up to the buildsystem that the source code uses internally, e.g. autotools, cmake, meson,... Apr 23 14:56:33 prabhakarlad: if your code wants to use glib then it should use pkgconfig to get the flags as usual Apr 23 14:59:16 LetoThe2nd: rburton: thank you for your suggestion I did manually add the includes something like this "TARGET_CFLAGS += "-I${STAGING_INCDIR} -I${STAGING_INCDIR}/glib-2.0 -I${STAGING_LIBDIR}/glib-2.0/include/"" , as I am adding my custom application Apr 23 14:59:58 since I am not using the autotools, cmake I had to manually add them.. Apr 23 15:00:19 prabhakarlad: then you're doing it wrong, cmake can certainly use pkg-config to properly detect them Apr 23 15:02:07 LetoThe2nd: sorry for my typo earlier I meant I am not using cmake/autotools/meason, I have just a simple Makefile Apr 23 15:04:23 prabhakarlad: well then, enjoy the pain :-D Apr 23 15:04:43 you should *totally* still pour pkg-support into it Apr 23 15:05:38 prabhakarlad: use pkgconfig from your makefile Apr 23 15:13:29 rburton: Yes thats a good option to use pkgconfig from your makefile thank you :) Apr 23 15:23:07 I know it is possible to share sstate between mulitple builders over NFS, is it also possible (safe?) to share the download cache over NFS? Apr 23 15:38:58 JPEW: i wouldn't trust nfs locking enough to do that Apr 23 15:43:46 rburton: sstate, downloads, or both? Apr 23 15:58:12 JPEW: anything. don't trust nfs :) Apr 23 15:59:38 we have been using nfs for quite some time now without issues, there was a locking issue we faced which is already upstreamed into bitbake Apr 23 16:00:29 iirc you potentially have races to write to DL_DIR but the worst case is two machines download the same file and put it in the cache, there's no corruption Apr 23 16:01:02 yeah ofcourse, we do not write to it simultaneously Apr 23 16:01:24 there is one autobuilder task to rsync it from official builds Apr 23 16:02:30 one good thing with nfs is that it will symlink into dldir of the consumer build so kind of saves space Apr 23 16:02:48 JPEW: it is possible to share sstate between mulitple builders over NFS but is not working though Apr 23 16:03:44 I dont think if you want consumers to share its possible but if you want to write to sstate cache at same time I would recommend not to Apr 23 16:04:15 JPEW: fwiw the yocto autobuilder has the master do a fetchall to populate DL_DIR once, and then sstate is rsync'd to the master after every build (using the master as a read-only sstate mirror) Apr 23 16:04:27 khem: Hmm, ok. Do you know when that bitbake issue was fixed? Apr 23 16:04:35 so have a official build like nightly or something populate/refresh the sstate everyday and then run with that ssate for rest of day Apr 23 16:04:47 log time ago probably a year or so Apr 23 16:05:22 K, that might not be recent enough for us, we are sadly still on morty Apr 23 16:05:33 you can choose to do official builds more often than 24hrs Apr 23 16:05:50 morty will have it Apr 23 16:06:17 Ya, we have been using sstate over HTTP, but our nightly builds are.... questionable to say the least (which is an entirely different story) Apr 23 16:06:49 http://git.openembedded.org/bitbake/commit/?id=5a53e7d7b017769a6eb0f0a6335735a1fe51a5ec Apr 23 16:07:01 khem: so you are using NFS for read-only sstate? Apr 23 16:07:06 yes Apr 23 16:07:18 and also for download mirror Apr 23 16:07:37 JPEW: NFS and sstate works only as read only Apr 23 16:07:39 based on ubuntu 14.04 Apr 23 16:08:05 OK, that makes sense. Thanks all Apr 23 16:24:36 RP, don't take any stable/*, I broke all of them :) Apr 23 16:24:49 armpit: nice :) Apr 23 16:48:45 armpit: skills! Apr 23 17:56:26 why is there no image feature for wayland/weston like there is for x11, x11-base, and x11-sato? Seems like a majour oversight... Apr 23 17:57:19 like how is one supposed to do something like "${@bb.utils.contains('IMAGE_FEATURES', 'wayland-base', "packagegroup-mygroup-wayland", "", d)}" Apr 23 18:28:37 Can I fetch files for a .bbappend though a git repo? Apr 23 18:29:04 I tried adding the git path to the SRC_URI but it doesnt seen to work Apr 23 18:34:56 hello Apr 23 18:35:07 is anyone involved in mingw layer maintenance? Apr 23 18:45:49 New news from stackoverflow: How to add a new library using Yocto Apr 23 19:00:10 how would I make a do_unpack_append? doesn't seem to work for me Apr 23 19:02:24 Fetch & unpack are pretty special. You might be better with a _prepend on a later function instead of an _append on do_unpack Apr 23 19:02:57 ah okay, what about do_patch? could I make an append on that then? Apr 23 19:03:29 I've never actually looked where do_patch is implemented. Give it a try and see what happens :) Apr 23 19:04:26 are you trying to write your append in shell or python? Apr 23 19:04:33 in shell Apr 23 19:05:14 but I really need to either make a shell script execute after either unpack or before patch Apr 23 19:05:24 Ah ok. Those early tasks are in python Apr 23 19:05:36 ah I see Apr 23 19:05:36 You could define a new task between unpack and patch that can be in shell Apr 23 19:06:33 paulbarker: I need the WORKDIR definition in the bb file which I am writing a bbappend for Apr 23 19:06:55 it seems it can actually call my new task after do_patch but it can't see the WORKDIR definition now Apr 23 19:07:13 I used do_patch[postfuncs] to call this shell code Apr 23 19:07:34 I think postfuncs is the wrong approach, not sure what that has access to Apr 23 19:07:56 Have a look at https://www.yoctoproject.org/docs/2.4.2/bitbake-user-manual/bitbake-user-manual.html#promoting-a-function-to-a-task Apr 23 19:08:17 but obviously substitute a shell function instead of the python function used in the example Apr 23 19:18:35 paulbarker: seems like it adds my function now but something odd about it as it doesn't seem to be run Apr 23 19:19:12 oiy, why does my packagegroup (seem to) RDEPEND every packagegroup defined inside it? I want to be able to choose either x11 or wayland or both, but I always end up with both... Apr 23 19:19:22 https://pastebin.ca/4018018 Apr 23 19:19:27 ksj: could you post the bbappend via a pastebin? Apr 23 19:20:14 yea will do that Apr 23 19:21:47 even if I bitbake -g packagegroup-myproject-cli (Which specifically doesn't include -x11 or -wayland ) I get *both* versions of chromium showing up in the depends.dot files and the pn_buildlist Apr 23 19:22:17 paulbarker: https://pastebin.com/raw/JF84KaGe Apr 23 19:22:58 ksj: You've said your task needs to be after do_patch but not before anything. So nothing depends on your task Apr 23 19:22:58 I can see thatt he files are put into the $(WORKDIR) folder Apr 23 19:23:10 paulbarker: there's nothing running after this task Apr 23 19:23:21 Try "addtask something_j120 after do_patch before do_configure" Apr 23 19:23:28 or "before do_patch" Apr 23 19:24:25 paulbarker: ah that seemed to work but now it says it can't see my directories in the $(WORKSPACE) Apr 23 19:25:01 "cannot create regular file '/Linux_for_Tegra/': Not a directory" Apr 23 19:25:42 You need to use {} not () Apr 23 19:25:56 oh lol Apr 23 19:26:08 aarcane: Not sure you need to set PROVIDES, that might be causing bitbake some confusion Apr 23 19:26:10 paulbarker: wait I am using {} Apr 23 19:26:17 I mistyped in irc Apr 23 19:26:36 ksj: In the pastebin file you have both {} and () Apr 23 19:27:53 oh god what am I doing Apr 23 19:28:27 huh would you look at that, it did the trick :p Apr 23 19:28:30 thanks a lot paulbarker Apr 23 19:48:39 paulbarker, if I do that, I get "Nothing PROVIDES 'packagegroup-myproject-cli'. Close matches:" Apr 23 19:52:24 Looking at http://git.openembedded.org/openembedded-core/tree/meta/recipes-sato/packagegroups/packagegroup-core-x11-sato.bb for reference you shouldn't need to set PROVIDES Apr 23 19:53:45 I would avoid making PACKAGES conditional on DISTRO_FEATURES. Maybe define packagegroup-myproject-gui where the contents of it's RDEPENDS is dependent on DISTRO_FEATURES instead Apr 23 19:57:44 paulbarker, I used core/packagegroups/packagegroup-base.bb as a template, built up from there Apr 23 20:00:21 paulbarker, anyway, if I just throw both packages into PACKAGES then I just get both installed no matter which I request. Apr 23 20:01:07 ok, that is strange. Just read through packagegroup-base.bb and looks like you're doing pretty much the same as it is doing Apr 23 20:01:27 I hadn't seen PROVIDES set for a packagegroup recipe like that before Apr 23 20:02:13 One concern is that you're mixing quotes when you use bb.utils.contains Apr 23 20:02:40 should I use all ' or all " ? Apr 23 20:02:58 If your outer quotes for PACKAGES is "", you should probably stick to '' inside as I'm not sure how bitbake's parser handles nested quotes Apr 23 20:05:20 Oh, hang on. You don't define packagegroup-myproject in PACKAGES but you set RDEPENDS for it Apr 23 20:05:37 paulbarker, I've added and removed both extensively Apr 23 20:05:48 paulbarker, no change on either Apr 23 20:07:51 I'm a bit lost then and I need to get going sorry. Last suggestion is to do a really basic check, run `bitbake packagegroup-myproject -e` and check that DISTRO_FEATURES, PACKAGES and RDEPENDS for each package is set as you expect Apr 23 20:17:42 and of course a packagegroup apparently has no knowledge of IMAGE_FEATURES because keying on that does no good... Apr 23 21:42:57 uhm... since I'm planning largely a read-only rootfs and no installable packages.. can I configure yocto to not build packages, and if I do, will it still be able to populate the rootfs and create a functional image? Apr 23 21:43:53 A read-only rootfs still requires packages. They get installed into build the image, then it is made read-only after that Apr 23 21:44:06 (basically) Apr 23 21:44:24 JPEW, I was afraid of that, but was hopeful it could use the built software without first packaging and then depackaging it. Apr 23 21:45:33 basically to save some CPU time and maybe disk space (I don't know how much of the built files are kept around...) Apr 23 21:47:25 If you're worried about the disk space, you can do INHERIT += "rm_work" in local.conf Apr 23 21:47:48 https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-rm-work Apr 23 21:48:11 JPEW, not that worried. It just seems a waste to package and then unpackage if I'm never going to update as a single package, y'kno? Apr 23 21:50:25 aarcane: Sure. I assure that as you get more use to it, you'll realize it makes perfect sense to do it that way :) Apr 23 22:51:33 IMAGE_FEATURES is image-specific by definition. it can differ from one image to another, at the time we build a packagegroup we have no idea what images will install it. Apr 23 22:51:37 aarcane: ^ Apr 23 22:53:38 kergoth, that makes sense, except that if we build an image, we have IMAGE_FEATURES set when we include the packagegroup, and can therefore only build or provide the packages and packagegroups we need now, and build the rest later. Anyway... Not sure what I changed, but I got it working finally. also, pn_buildlist and the other .dot files build with -g don't accurately reflect the image output... Apr 23 22:53:52 no, you're misunderstanding how the build works Apr 23 22:54:01 recipes produce binary packages which are then installed by image recipes Apr 23 22:54:07 that binary package is created once, not once per image Apr 23 22:54:16 kergoth, correct Apr 23 22:54:22 packagegroups emit empty binary packages with specific depnedencies Apr 23 22:54:26 they are not pure metadata Apr 23 22:54:35 Hmm... Apr 23 22:54:57 that makes sense and is pretty much what I expected Apr 23 22:55:54 it sounds like you might just want to bypass the packagegroup entirely in favor of explicit dependencies in the image, either directly in IMAGE_INSTALL or via image features Apr 23 22:56:10 or alter how both the image and packagegroup are constructed with a distro feature, depending on your requirements Apr 23 22:57:23 I just want to key off IMAGE_FEATURES to know which packagegroups to install... and I have that working finally. I had to create a new bbclass that inherits core-image and adds some new FEATURE_PACKAGES and IMAGE_FEATURE_CONFLICTS tags to it. Apr 23 22:57:47 ah, yes, that's definitely doable Apr 23 22:58:32 since I have one distro, one basic everything, and the only difference between the two images (Future: 3) is which graphical environment loads the webpage and throws it onto the touch screen. Apr 23 23:01:59 now I'm struggling slightly with needing a package version other than the latest and no option to specify RDEPENDS pkgname == version and therefore which .conf file to plug it into. It's in layer.conf now since the version requirement is for a package in the layer and I'm not building a *custom* distro, just using poky. Apr 24 00:10:46 if I switch from rpm to ipkg, after an initial repackaging of everything, can I reasonably expect improved times for do-rootfs? right now it takes several minutes... or is it more likely IOP bound and not worth switching? Apr 24 00:12:30 if I don't have to rebuild everything, it'll be worth it, if I do have to rebuild everything, it won't be... **** ENDING LOGGING AT Tue Apr 24 03:00:01 2018