**** BEGIN LOGGING AT Tue Nov 27 03:00:01 2018 Nov 27 07:19:27 What's the compiler optimization flag is Yocto using to compile its packages? Nov 27 07:49:44 -O2 generally, but its a series of flags you should check bitbake -e and check for CFLAGS and CC variable settings Nov 27 08:02:55 good morning Nov 27 08:07:00 How can I find the DISTRO_FEATURES that I'm using? Nov 27 08:08:16 I'm still trying to sort out the wifi situation on my meta-raspberrypi image. I've added networkmanager, but I'm not sure how to start it and add a config file. Nov 27 08:14:21 Trying to use the kernel-yocto.bbclass for a custom tree and I'm having some issues with applying a patch. It seems like do_patch() always create a symlink from 'series -> patch.queue' even though the branch option in a given scc file changes the name of the patch queue. Am I missing some variable or something that determines this? Nov 27 08:43:50 I guess I would have to just read the kgit-meta and scc scripts Nov 27 09:12:57 huh, I added systemd to my local.conf and now it's recompiling the whole universe. Nov 27 09:14:14 pepijndevos: usually one adds it to the custom DISTRO... but yes, the impact is rather massive. Nov 27 09:17:22 oh... hmm, making a custom DISTRO sounds way nicer than putting random shit in local.conf. I'll look into that. Nov 27 09:22:21 pepijndevos: local.conf is usually good for "ummmm lemme give that a try" after, that, move stuff to approriate places for reproductibility. Nov 27 09:22:45 pepijndevos: in almost all projects you will have a custom MACHINE, custom DISTRO and custom IMAGE Nov 27 09:27:01 What are the bottom 3 lines for here? http://forum.variscite.com/viewtopic.php?t=343 Nov 27 09:27:53 pepijndevos: each setting should be neatly explained here: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#selecting-an-initialization-manager Nov 27 09:30:24 khem, Thanks Nov 27 09:32:14 I read that, but not thoroughly enough. Now reading how backfill works. Still not sure what the "virtual runtime" refers to. Sounds to me like some qemu thing. Nov 27 09:38:54 pepijndevos: i would interpret the VIRTUAL-RUNTIME_xxxx as "package that provides the functionality of xxxx at runtime". you can have different recipes that provide VIRTUAL-RUNTIME_init_manager, for example Nov 27 09:59:32 pepijndevos: virtual as in not real: init-manager is a package name that never actually exists, just other packages provide it Nov 27 09:59:38 so systemd provides init-manager Nov 27 09:59:42 so does sysvinit Nov 27 10:07:08 ahhh makes sense Nov 27 10:54:25 What is the correct way to enable wifi and add a config to connman? Basically so it connects to the right network on first boot. Nov 27 10:57:51 Basically by default there is a file in /var/lib/connman/settings that contains [WiFi] Enabled=false, but I don't see where it is created. Nov 27 11:21:54 New news from stackoverflow: ADV7513 on yocto - kernel 4.14 Nov 27 11:56:00 Hi all! Can I ask a Poky related question here? I'm pretty new to Yocto as a system, so this may be an easy question: How do I install SSL certificates in Poky (2.3.2)? Nov 27 11:56:22 (I asked in #Poky, but it seems pretty quiet there) Nov 27 11:57:35 laumann: no idea about #poky, but generally you are correct here. just what do you mean exactly by "install ssl certificates"= Nov 27 11:59:24 LetoThe2nd: I'm trying to do 'curl https://google.com' (for instance) and am getting: curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none Nov 27 12:00:29 laumann: just add ca-certificates to your image. -> http://layers.openembedded.org/layerindex/recipe/5903/ Nov 27 12:02:12 LetoThe2nd: thanks, I guess this is where my n00bness in Yocto comes in: I have a gateway that came with Poky pre-installed, and this is the one I'd like to add the CA certificates to Nov 27 12:02:17 can I modify that image? Nov 27 12:02:50 hum no, this is not how things work in openembedded. Nov 27 12:03:21 unless that image for some reason has package management enabled, which is rare IMHO Nov 27 12:03:29 LetoThe2nd: that's what I feared :-) Nov 27 12:03:46 I'm not even sure what package manager this has (if any) Nov 27 12:03:50 not apt, for sure Nov 27 12:04:26 i mean, you can test if there is something like dpkg or rpm there. but in that case, you're probably better off just getting the certificate archive, and manually extract + place it at the respective destinations. Nov 27 12:05:21 laumann: you have to think of yocto/OE as a toolkit that *builds* your distribution, and not *is* a distribution. that means who ever sold that gateway created a custom linux distribution to run on it. Nov 27 12:05:46 LetoThe2nd: Ah thanks! Looks like there's rpm Nov 27 12:05:51 which product is that, by the way? Nov 27 12:06:01 LetoThe2nd: but I'm up for doing this manually Nov 27 12:06:07 LetoThe2nd: Just a sec, let me find it Nov 27 12:06:13 if no explicit preferred version is defined, how's the preferred version determined? lexicgraphical order? Nov 27 12:06:34 T_UNIX: highest version, should be Nov 27 12:06:37 LetoThe2nd: It's this one: https://www.eurotech.com/en/products/subsystems/edge-computers/dynagate-10-12 Nov 27 12:07:19 laumann: looks like a beaglebone black with a fancy case + some special sauce Nov 27 12:07:26 ah, Debian. Nov 27 12:08:11 LetoThe2nd: their manual is not quite specific about the Linux: it just says "Yocto Linux" Nov 27 12:08:20 which isn't very helpful :P Nov 27 12:08:24 laumann: which is technically an incorrect term Nov 27 12:08:30 LetoThe2nd: Yeah, I know Nov 27 12:08:48 LetoThe2nd: but I've been able to determine that it's a Poky of some sort Nov 27 12:09:12 LetoThe2nd: How can you tell it's a beaglebone? Nov 27 12:11:01 laumann: i'm not saying it *is* really a beaglebone inside, but the HW specs look extremely similar to the BBB, so i suspect its either one inside (possible) or a design closely based on it (more probably, actually) Nov 27 12:11:48 LetoThe2nd: ok Nov 27 12:12:45 laumann: but their github account does not offer the layers they used. so if this is more than a one-off tinkerin product, you seriously need to pester their support into handing out the proper sources (which they are obliged too anyways, with the metadata being sometimes subject to discussion) Nov 27 12:14:33 LetoThe2nd: ok, I'll get a hold of them Nov 27 12:15:58 laumann: i mean, you probably don't want to manually beat the root fs into shape on every unit you ship. let alone update core parts, or add new software that has to be crosscompiled against libraries in specific versions, right ;-) Nov 27 12:16:12 so you need the building metadata to create your own images. Nov 27 12:18:18 LetoThe2nd: hehe, no :-) Nov 27 12:18:47 see. good luck! Nov 27 12:20:34 LetoThe2nd: Thanks for the help! Until I get the sources, I'll try installing the certificates manually... we'll see how it goes Nov 27 12:20:38 kanav Nov 27 12:21:23 typo :) Nov 27 12:27:00 We have too many "'random" selftest failures :( Nov 27 12:32:11 rburton_: do you think the cpio segfault could be due to files changing under it? Wondering if we should put an inotify monitor over the do_image* tasks and see if something is writing there Nov 27 12:35:04 I have a commercial package with a custom package format that installs target libraries in a folder in $PACKAGE_NAME. It's probably bad practice, but can I make a recipe that install files from the location specified by this environment variable? Nov 27 12:36:08 pepijndevos: manually unpack and do install magic, sure. look at the bin_package class (or whatsit called, something similar) Nov 27 12:49:26 How can I reference an environment variable with an absolute path in SRC_URI? Nov 27 12:52:01 RP: interesting idea to catch changes Nov 27 12:52:19 RP: a general-purpose "during this with block, this directory shouldn't change" would be awesome Nov 27 12:57:06 rburton_: can't think why cpio would fault otherwise :/ Nov 27 12:59:47 rburton_: I've put a few debugging patches in -next and run lots of selftests, will see if that shows anything. Its hot sstate so may not be so good at showing them up Nov 27 13:00:08 not the inotify one though, still need to figure out how to implement that Nov 27 13:12:15 So... this binary package includes target arch libraries, but also a few host arch binaries. Can I make sortof a host package that's used for compiling stuff that depends on it? Nov 27 13:17:27 pepijndevos: should be doable through the PROVIDES mechanism, i guess. but you're in for a lot of pain, and always remember the licensing restrictions that this said lib might impose on your product Nov 27 13:24:39 LetoThe2nd, with RTI Connext, I'm not expecting anything less than living hell :( Nov 27 13:25:24 rti? Nov 27 13:25:51 https://www.rti.com/products/connext-dds-professional Nov 27 13:26:56 hrhrhr Nov 27 13:27:07 pepijndevos: i'd have two recipes that use the same SRC_URI but package up either the host stuff (foo-native) or target stuff (foo) Nov 27 13:28:16 Basically, they give you a host installer which includes code generators for message definitions. In order to be able to cross-compile my software, I somehow need to invoke that thing. Nov 27 13:29:14 yeah, we've seen things like that many times Nov 27 13:29:14 rburton_, sure, how do I make a foo-native package that can be used to compile stuff, but not end up on the image? Nov 27 13:29:28 pepijndevos: -native packages do not go into the image Nov 27 13:30:29 So I just call it -native and I'm good? I'm now looking at this cross class, is that relevant? Nov 27 13:31:11 pepijndevos: call it foo-native, inherit native in it, and most importantly don't put it in the image in the first place :) Nov 27 13:31:18 cross class is only relevant if you're buiding a cross compiler Nov 27 13:33:59 awesome, I'll try Nov 27 13:36:27 Can recipes have underscores in their names? Seems not. Nov 27 13:51:19 hello, is it just me or is the "usrmerge" for DISTRO_FEATURES not documented in the latest Yocto project manual? At least it does not seem to be in the 2.6 Mega-manual Nov 27 13:52:28 New news from stackoverflow: How to handle two kernel recipes in parallel? Nov 27 14:05:34 rburton_: test runs shows other failures, all different :( Nov 27 14:07:04 RP: argh Nov 27 14:07:46 as opposed to all the same? Nov 27 14:12:34 Nobody laughs at my jokes, must be too old Nov 27 14:19:53 what joke? Nov 27 14:20:56 in this definition of the variable S it is stated it is "where unpacked recipe source code resides," but I don't understand how or why recipes are unpacked. are they not static from the /sources paths? Nov 27 14:21:25 because most recipe sources are tarballs Nov 27 14:21:43 yates: recipes are not unpacked. "recipe source codes", eg. that what the recipe refers to, is unpacked if needed. Nov 27 14:21:50 oh! Nov 27 14:22:01 ok, parse error... :) Nov 27 14:22:20 all is right with the world once again.. Nov 27 14:22:45 everything in SRC_URI is fetched (do_fetch, put in DL_DIR) then unpacked (do_unpack, untarred to $S for tarball, just copied for plain files, git checkout for git) Nov 27 14:23:13 right Nov 27 14:24:38 Uhm, so I have a -native package now. How can I use it in another package? The native package puts files in build/tmp/work/x86_64-linux/dds-native/5.3.1-r0/image it appears Nov 27 14:25:15 pepijndevos: -> DEPENDS Nov 27 14:25:27 Yea, but what's the path after that? Nov 27 14:26:51 pepijndevos: you put package-native into depends, and then "use" it as it is installed in the host system Nov 27 14:26:56 s/system/sysroot/ Nov 27 14:27:38 Oh, so it's like [...]/image/blah is actually /blah Nov 27 14:27:45 cool cool Nov 27 14:28:23 yeah image/ is just a staging directory Nov 27 14:28:42 *everything* in tmp/work/* is staging and can be deleted Nov 27 14:29:04 when your recipe depends on foo-native it puts the contents of foo-native into your sysroot Nov 27 14:29:12 which is on $PATH, so binaries just work Nov 27 14:31:49 where is the W variable defined? Nov 27 14:32:04 i looked in two manuals' glossaries and can't find it Nov 27 14:34:37 isn't there a ${W} variable? i thought i saw it used, in do_compile? Nov 27 14:35:18 yates: there is S, B and D Nov 27 14:36:25 LetoThe2nd: thank you. Nov 27 14:41:30 rburton_, my -native package installed stuff in non-standard locations, and it does not seem to be in the sysroot or the path. Nov 27 14:45:49 I moved the files out of their prefix, so now I have /tmp/work/x86_64-linux/dds-native/5.3.1-r0/image/bin/rtipkginstall and in the other package I do DEPENDS += " dds-native" but then rtipkginstall gives me command not found. Nov 27 15:01:29 RP, rburton: Thanks for getting the AB building and testing MinGW Nov 27 15:06:29 there is nothing much in recipe-sysroot[-native], is that normal? Nov 27 15:07:42 This is my recipe now https://paste.ubuntu.com/p/tPbPT3pDnM/ Nov 27 15:08:24 pepijndevos: LICENSE is not CLOSE, LICENSE is Proprietary :) Nov 27 15:08:40 (as a side note) Nov 27 15:09:26 pepijndevos: i suspect bin isn't in the path, try usr/bin Nov 27 15:12:17 (can I force the thing to rerun the whole recipe?) Nov 27 15:13:08 JPEW: Thanks for sorting the patches! We're testing 64 bit only atm but even that is a huge win Nov 27 15:14:32 rburton_, I have /home/rove/code/poky/rpi-build/tmp/work/x86_64-linux/dds-native/5.3.1-r5/image/usr/bin/rtipkginstall now, but ls /home/rove/code/poky/rpi-build/tmp/work/x86_64-linux/dds-native/5.3.1-r5/recipe-sysroot-native/usr/bin/ contains only guards quilt Nov 27 15:20:46 ah... I'm onto something Nov 27 15:26:02 it works! I copied shit to ${bindir} and that points straight to the sysroot Nov 27 15:27:51 Well... that part worked... still getting "not found" when I try to build the dependant package Nov 27 15:33:01 Where is the actual sysroot itself located? Nov 27 15:33:37 recipe-sysroot-native is where the DEPENDS of the recipe have their binaries Nov 27 15:33:39 not the recipe itself Nov 27 15:33:44 and you can't run the binaries of the recipe you just built Nov 27 15:33:48 so not sure what you're tryig to do there Nov 27 15:38:21 kergoth, I'm trying to install binaries in a native package and use it from another one. Nov 27 15:40:49 sorry, pc crashed... having a great day haha Nov 27 15:42:02 kergoth, this is my recipe now https://paste.ubuntu.com/p/GD8KqqcPwj/ Nov 27 15:42:54 That moves all the thins into build/tmp/work/x86_64-linux/dds-native/5.3.1-r5/recipe-sysroot-native somehow... Nov 27 15:45:30 I've tried to just move to ${D}/usr/bin, but that doesn't work either.. Nov 27 15:47:53 target should DEPENDS on the native recipe, native recipe should install to ${D}${bindir} in do_install, then the target recipe can run it from configure, compile, or install Nov 27 15:48:07 nothing else to it, other than ensuring the native recipe inherits native, of course, one way or hte other Nov 27 15:52:07 pepijndevos: those mv's are wrong Nov 27 15:52:40 you're missing a ${D} in the target Nov 27 15:52:53 also the mkdirs need ${D} too Nov 27 15:52:55 New news from stackoverflow: Handling failed task in Yocto recipe Nov 27 15:53:18 also PR isn't needed unless you're maintaining a feed, in which case dont use manual PR changes but use the PR server Nov 27 15:54:04 OH GOD YAY FINALLY Nov 27 15:54:31 inside do_install *everything needs to go into ${D}* Nov 27 15:54:38 D for Destination Nov 27 15:55:09 YPTM: Armin is on Nov 27 15:55:18 I printed ${D}${bindir} and it printed something ridiculous that seemed like ${bindir} was an absolute path. So that's why I figured I should skip the D part. Nov 27 15:55:21 armin is very early Nov 27 15:56:57 So... that worked for bin and include, but now the binary is complaining it can't find some resource files... these were obviously not copied into the sysroot. Nov 27 15:57:52 rburton_, is it still an hour away.. I am MT timezone today Nov 27 15:58:36 armpit: no, you're just five minutes early Nov 27 15:58:40 armpit: no, there is one now Nov 27 15:59:08 pepijndevos: staging doesn't copy everything, you'll need to add that non-standard path to SYSROOT_DIRS Nov 27 15:59:11 (see staging.bbclass) Nov 27 15:59:52 armpit: are you on hold? Nov 27 16:00:40 awesome Nov 27 16:01:10 RP, no, I use the mute button on my phone Nov 27 16:01:19 armpit: do you have the bridge number? Nov 27 16:01:19 YPTM; ross on Nov 27 16:01:30 YPTM on Zoom:Bridge is with Zoom at: https://zoom.us/j/990892712 Nov 27 16:01:36 thanks Nov 27 16:01:37 YPTM: Stephen Joined Nov 27 16:02:08 YPTM: Richard joined Nov 27 16:02:08 YPTM: Randy joined Nov 27 16:02:15 YPTM: David joined Nov 27 16:02:34 YPTM: Armpit is on Nov 27 16:02:35 Ross Nov 27 16:03:22 Aaron Chan has joined the Zoom Meeting Nov 27 16:08:05 2.7 Planning doc: https://docs.google.com/document/d/15jB6nUJU2wrtnu6w07L9RZpNlj6AoxSTPEX5aELts1g/edit Nov 27 16:10:29 Thanks Nov 27 16:13:41 hrm... I've deleted all the manual moving because it break the structure, and added SYSROOT_DIRS += " ${D}/rti_connext_dds-5.3.1" in the hope that it'd add the whole folder. That does not seem to happen... Nov 27 16:14:14 Alright... I'll firgure this out tomorrow. Nothing works today... Nov 27 16:14:14 not ${D}, the paths there are relative to the base of the sysroot Nov 27 16:14:19 oooooh Nov 27 16:14:33 so i'd guess adding "/rti_connext*" will work and be future proof Nov 27 16:17:25 Okay, that looks slightly more promising... thanks so much. I'll figure out the final details tomorrow. Nov 27 16:22:18 oh wow I didnt know there was a meeting today Nov 27 16:25:29 YPTM: Alejandro joined Nov 27 16:29:40 at do_install_append time, should any utility (specifically wx-config) generated by autotool which got installed in $(bindir) be in the XYZ/usr/bin of the PATH? Nov 27 16:31:17 by hacking some echos in the do_install_append, i'm seeing the usr/bin path at /tmp/sysroots-uninative/x86_64-linux/usr/bin Nov 27 16:32:22 but looking there after the do_install_append exits all i can find is a patchelf-uninative - no other files or subdirs.. Nov 27 16:33:06 totally OT, but https://arstechnica.com/tech-policy/2018/11/how-i-changed-the-law-with-a-github-pull-request/ is awesome Nov 27 16:34:37 yates: do_install writes to a staging area, which is unrelated to where you can run stuff from Nov 27 16:36:26 rburton: ok, but i don't want to run anything. the endgame is to get the generate wx-config into my package. Nov 27 16:37:15 i'm pretty sure the autotools is generating it because grepping shows this: https://paste.fedoraproject.org/paste/g8u7e8iTktr5rcuNWrGsDg Nov 27 16:38:44 i'm just have a hard time getting at it (e.g., for FILES) at do_install_append time Nov 27 16:39:22 remember a few days back ya'll also had me do this GLOB because the wx-config was a symlink: BINCONFIG_GLOB = "inplace-arm-fslc-linux-gnueabi-gtk2-unicode-3.0" Nov 27 16:39:48 right Nov 27 16:40:50 FILES_${PN} = "${bindir}/wx-config ${bindir}/wxrc-3.0 ${bindir}/wxrc ${libdir}/wx ${includedir}/wx-3.0 ${libdir}/libwx*" Nov 27 16:41:07 that apparently does not pick up the wx-config into the package Nov 27 16:41:49 have a look at binconfig.bbclass Nov 27 16:41:53 specifically the first line Nov 27 16:41:57 because building a subsequent recipe that DEPENDS on this recipe (i call it simply wxwidgets_3.0.4.bb) can't find wx-config Nov 27 16:42:45 you mean this: FILES_${PN}-dev += "${bindir}/*-config" Nov 27 16:42:53 yes Nov 27 16:43:01 thats why its not in PN, because it should be in PN-dev Nov 27 16:43:07 so i'd verify that is happening Nov 27 16:43:30 stop putting includedir in PN Nov 27 16:43:47 seriously just delete your FILES Nov 27 16:43:52 let the standard rules do the right thing Nov 27 16:44:16 i was geting qa error. Nov 27 16:44:29 getting Nov 27 16:44:54 you'll definitely get a QA error if you put development libraries into PN Nov 27 16:45:07 fwiw, still unsure why you didn't just update the existing recipe Nov 27 16:50:24 when building with multilib, what approach do you suggest to build all packages except the kernel as 32bit application? Nov 27 16:52:21 rburton: re: development libraries: the include files are supposed to be part of the package, are they not? Nov 27 16:52:29 the PN-dev pacakge Nov 27 16:52:38 as per the standard FILES Nov 27 16:52:54 PN has the actual libraries, PN-dev has the development library links, and headers Nov 27 16:53:16 for wx I'd expect all of $bindir to be in PN-dev too Nov 27 16:53:26 rburton: ok with next up to uboot-sign? Nov 27 16:53:38 yates: the important distinction is what is needed to run something using wx vs what is needed to build against wx Nov 27 16:53:55 * rburton looks Nov 27 16:54:40 rburton: yes, i understand that difference. but i wanted this recipe to provide both the run-time libraries (.so's) AND the files needed for development (the includes, the wx-config utility) Nov 27 16:54:50 yates: why not just install PN and PN-dev Nov 27 16:55:02 you'll end up arguing with the QA Nov 27 16:56:24 so you mean the standard rules will generate both wxwidgets and wxwidgets-dev RPMs automagically ??? Nov 27 16:56:56 yes Nov 27 16:56:59 derRichard: bitbake lib32-core-image-foo should work, no? Nov 27 16:57:00 * yates facepalms Nov 27 16:57:10 yates: bitbake.conf, look at PACKAGES and all the FILES Nov 27 16:57:22 * vmeson builds that now but in a WR Linux env. Nov 27 16:58:39 RP: the hostname thing is horrible Nov 27 16:58:47 been meaning to review that, wish i did earlier Nov 27 16:59:49 rburton: how should we do it though? Nov 27 17:02:36 i need to add the ${PN}-dev to the recipe's PROVIDES if i want to DEPENDS on it by another recipe? Nov 27 17:03:05 yates: DEPENDS works on recipes not pacakges Nov 27 17:03:09 so just DEPENDS=wxwidgets Nov 27 17:09:30 RP: move hosts to base-files so it can be written at the same time? Nov 27 17:09:39 rburton: do i need to add PROVIDES += "${PN}-dev" in the wxwidgets recipe if i want the wxwidgets-dev.rpm package to be available at target system runtime? Nov 27 17:10:04 (i'm generating a repository and using it with smart) Nov 27 17:10:16 yates: no, its a package, so its available Nov 27 17:10:39 also PROVIDES is built-time, you'd be talking about RPROVIDES. but no. Nov 27 17:12:00 so if a ra DEPENDS on rb, then it automatically gets rb-dev files at build-time? Nov 27 17:12:57 if so, something is hosed. i'm still getting "wx-config: not found" problem in ra at bitbake time. Nov 27 17:14:01 i removed my FILES in wxwidgets Nov 27 17:14:18 wxwidgets_3.0.4.bb: https://paste.fedoraproject.org/paste/phslD8vbuJ2FIDv0BnRaZQ Nov 27 17:14:38 client-6300-devel_1.0-rc0.bb: https://paste.fedoraproject.org/paste/N1h7ZMwAqtDEZbaIuEhZLw Nov 27 17:16:11 vmeson: aaaahh, i can use the lib32-prefix here too. very nice. thx! Nov 27 17:19:15 doh. i am deleting files which include wx-config in the wxwidgets do_install_append(). i undeleted them, but then i'm getting QA errors. why aren't the "standard rules" putting those into the -dev package? Nov 27 17:19:58 what files? Nov 27 17:20:28 https://paste.fedoraproject.org/paste/OJ0W~EdM7z2cPD8oIGyaDw Nov 27 17:21:27 because the standard rules have no idea where those files go Nov 27 17:21:36 they look like they belong to PN-dev Nov 27 17:21:39 yes Nov 27 17:21:45 how do i finagle that? Nov 27 17:21:55 so FILES_${PN}-dev += "${libdir}/wx" Nov 27 17:22:06 oh! Nov 27 17:22:15 now you're not deleting the target of the wx-widgets symlink \o/ Nov 27 17:24:10 it really was a late-breaking revolution that a recipe generates both ${PN} and ${PN}-dev packages.. Nov 27 17:24:19 s/revolution/revelation? Nov 27 17:24:53 a recipe builds a package for everything in the cunningly-named variable PACKAGES Nov 27 17:25:11 if a package ends up empty, it doesn't get generated, unless ALLOW_EMPTY_[pkg] is set Nov 27 17:25:40 so even though PN-doc is in PACKAGES it is only generated if something is installed in $docdir, assuming default rules Nov 27 17:26:07 what are the default packages in PACKAGES? where is that instantiated? Nov 27 17:26:12 bitbake.conf Nov 27 17:26:54 ok. Nov 27 17:27:27 if the question is "where is...?" the first place to look is bitbake.conf Nov 27 17:27:50 the better answer is bitbake -e and look at the PACKAGES assignment history Nov 27 17:28:05 right Nov 27 17:28:49 still missing wx-config when attempting to build my dependent recipe. can i see the file system state (sysroot, etc) that was in-place in my dependent package's do_compile()? Nov 27 17:29:35 its in the work directory for that recipe Nov 27 17:29:43 here's the recipe i just used: https://paste.fedoraproject.org/paste/HuiP9D5WB1rMnNO0B6hmcw Nov 27 17:29:43 no doubt a bust symlink Nov 27 17:29:50 wxwidgets sounds *great* Nov 27 17:29:58 and... ? Nov 27 17:30:02 not so much? Nov 27 17:30:34 hillariously after all this you'll probably discover that the config script is so broken its useless Nov 27 17:30:46 maybe it will work, you never know Nov 27 17:30:58 but there's a very good reason why we try to kill them where possible Nov 27 17:31:28 yates, rburton: You may need to do something like the tcl recipe for a cross script, meta/recipes-devtools/tcltk/tcl_8.6.8.bb see the bindir_crossscripts bits Nov 27 17:31:49 as rburton says, we removed most of them Nov 27 17:32:34 things in bindir for the target are generally assumed not to be useful in a cross build Nov 27 17:33:00 * RP suspects rburton is blocking knowledge of the bad old days Nov 27 17:33:09 totally Nov 27 17:34:47 so you mean that the problem is whether a script is used only for building the libary versus for building applicaitons which use the library? Nov 27 17:35:13 the paths are likely wrong. the binconfig class tries to fix them. doesn't always succeed. Nov 27 17:35:27 try it, might work Nov 27 17:37:35 this is the contents of my dependent recipe's workdir: https://paste.fedoraproject.org/paste/fhHG8-4wydAnf6fDeWN4Xg Nov 27 17:38:05 i don't see any sysroot type files there Nov 27 17:38:32 this is after error-ing out from do_compile Nov 27 17:38:47 isn't that the ${WORKDIR}? Nov 27 17:38:55 oh is this an old yocto? Nov 27 17:39:01 morty Nov 27 17:39:09 right, shared sysroot Nov 27 17:39:16 there's a directory called sysroot above work Nov 27 17:39:45 https://paste.fedoraproject.org/paste/5W2RKFKd3tFsoa22d4qhkA Nov 27 17:39:54 you mean sysroots? Nov 27 17:41:03 rburton: given its our own file that would be an option Nov 27 17:41:26 ok, so the wx-config is present in sysroots/lib/wx/... Nov 27 17:41:32 rburton: I wonder if that would break things for people Nov 27 17:41:38 RP: check where it is pointing too Nov 27 17:41:40 erm yates ^ Nov 27 17:42:31 no, i mean the target of the symlink is there Nov 27 17:42:59 there is no symlink to it in sysroots/usr/bin though! no wx-config symlink there Nov 27 17:43:04 nada Nov 27 17:43:05 nil Nov 27 17:43:53 yates: look in usr/bin/crossscripts Nov 27 17:44:00 ah. Nov 27 17:44:05 target bindir is useless as you can't run anything Nov 27 17:44:18 some select pieces get put in crossscripts, like anything binconfig touches Nov 27 17:44:50 the original symlink target is there. scratch what i said about the symlink target being in /usr/lib/wx Nov 27 17:45:15 but like i said, no symlink to it in usr/bin Nov 27 17:45:41 and not in usr/bin/crosssripts Nov 27 17:45:51 right Nov 27 17:46:01 https://paste.fedoraproject.org/paste/eyhZT41fwD-jh2MEzkXXXw Nov 27 17:46:04 pass Nov 27 17:46:08 and on that note, dinner is on the table Nov 27 17:46:17 fish pie+++ Nov 27 17:46:21 ding! Nov 27 17:46:30 ha. enjoy dinner rburton. Nov 27 17:46:38 are you in Britain? Nov 27 17:47:10 or is it politically incorrect to ask location on irc? :) Nov 27 17:48:26 could i not just create a symlink in my do_install_append() there? Nov 27 18:29:19 vmeson: while bitbake lib32-core-image-foo seems to work fine, bitbake -c populate_sdk_ext lib32-core-image-foo does not Nov 27 18:29:28 can't i create such an sdk? Nov 27 19:07:44 is this issue still here? Nov 27 19:07:45 http://lists.openembedded.org/pipermail/openembedded-core/2017-November/262640.html Nov 27 19:07:57 reads like ext sdk and multilib is not possible Nov 27 19:57:54 derRichard: yeah, it would be nice to populate the sdk with just lib32 userspace. Care to re-open the defect: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12210 Nov 27 19:57:55 Bug 12210: normal, Medium+, 2.5 M2, liezhi.yang, RESOLVED FIXED, populate_sdk_ext failed when multilib Nov 27 19:58:33 There has been quite a bit of work on multlib support for 2.6 so maybe things have changed since early February. Nov 27 19:58:36 when building a recipe that DEPENDS on rdep, does yocto actually pull the files from rdep.rpm out of the deploy/rpms dir? Nov 27 19:59:03 vmeson: ok, i'll look into that :) Nov 27 19:59:26 btw: in meta-openembedded/meta-multimedia/recipes-multimedia/libdc1394/libdc1394_git.bb i see: Nov 27 19:59:29 S = "${WORKDIR}/git/${PN}" Nov 27 19:59:37 this seems to be broken for multilib, right? Nov 27 19:59:50 at least the build fails because make is unable to find the Makefile Nov 27 20:00:04 so i fear the name of the source path is wrong Nov 27 20:00:22 derRichard: if it doesn't build, it's a bug! s/PN/BPN/ ? Nov 27 20:00:24 * armpit hmm, layer index is not showing 'thud" Nov 27 20:02:52 rburton: i've discovered that the wxwidgets-dev.rpm package actually does list /usr/bin/wx-config. i don't know why it's not being installed Nov 27 20:04:54 via rpm -qlp wxwidgets-dev-3.0.4-r0.armv7at2hf_neon.rpm Nov 27 20:08:17 vmeson: so it is a bug to set S to PN? i always have to use BPN? Nov 27 20:08:25 at least from what i understand from the docs :) Nov 27 20:11:17 yates: hey, nice to see you here too :-D Nov 27 20:15:38 vmeson: hmm, that bugzilla entry makes me sad. does that mean i can't have an sdk at all when multilib is being used? Nov 27 20:29:17 hey derRichard from ##kernel! Nov 27 20:33:24 ok, i finally got wx-config to work Nov 27 20:33:30 ...sort of Nov 27 20:34:55 https://paste.fedoraproject.org/paste/TT1gcHl91zS9Lm7MGyhLsw Nov 27 20:37:56 can i get away with making a temporary edit to files in ${S} ? Nov 27 20:43:27 oh shit Nov 27 20:43:41 yates sees the light Nov 27 20:43:55 wx-config won't work for cross-compiling... Nov 27 20:44:10 what a pain in the rumpustoid Nov 27 20:44:40 is that what ya'll have been trying to tell me for a few days now? :) Nov 27 20:44:46 yates: it is amazing that in 2018 still many packages don't build cross ;-\ Nov 27 20:45:52 yeah, how to fix? write my own? Nov 27 20:47:29 usually i fix the package Nov 27 20:47:45 "-I /usr/..." won't work... Nov 27 20:48:50 --Wpoison-system-directories Nov 27 20:49:39 yes, that makes more sense Nov 27 20:49:48 don't reinvent the wheel, just fix it Nov 27 20:54:28 hmm, bitbake lib32-testing-image failed with: Nov 27 20:54:29 http://paste.debian.net/plain/1053469 Nov 27 20:54:33 whyt is apt trying to say me? Nov 27 20:54:38 *what Nov 27 20:54:51 bitbake lib32-dropbear works just fine Nov 27 20:54:58 why is lib32-dropbear not installable? Nov 27 21:05:36 yates: are you talking about installed into the sysroot? as i said, that's nothing to do with packages. Nov 27 21:07:33 yates: yes, you've now discovered why -config scripts are generally a nuisance Nov 27 21:07:59 if they all had a sysroot option, that would generally fix the problem, no? Nov 27 21:08:03 correct Nov 27 21:09:16 looking at the script there are --prefix and --exec-prefix options - i am not familiar enough to know if those can be used to do the same thing Nov 27 21:09:49 maybe i'm just not using it right??? Nov 27 21:09:57 https://paste.fedoraproject.org/paste/Q6pSL2nIZnmQIYHsRoodJg Nov 27 21:10:09 ^^^ that's from my x86 fedora system Nov 27 21:14:00 is the binconfig_package_preprocess only used to modify files used in the cross-build, or do those modified files get packaged? Nov 27 21:14:04 both Nov 27 21:14:08 i was just typing :) Nov 27 21:14:25 the sysroot_preprocess one tries to turn the paths into paths to the sysroot Nov 27 21:14:44 the package_preprocess one tries to remove any sysroot references that should be target paths Nov 27 21:15:54 if your config has e.g. /usr/ in then the sysroot one didn't do enough then try extending OE_BINCONFIG_EXTRA_MANGLE to add more replacements? Nov 27 21:16:19 well, i cheated with an extremely dirty trick... Nov 27 21:16:21 looks like upstream wx doesn't think pkgconfig is good enough and their stuff is fine Nov 27 21:17:01 (joining gnupg, we patch gpg-config out and write our own pkgconfig files) Nov 27 21:17:10 i put this in my recipe: binconfig_package_preprocess() {} Nov 27 21:17:19 so i just tossed all your neat mods... Nov 27 21:17:29 not too smart, i guess. Nov 27 21:17:47 *package*, won't touch the sysroot one Nov 27 21:19:01 what is ${PKGD} in your binconfig.bbclass? Nov 27 21:19:26 usr/bin ? Nov 27 21:19:52 hm, as soon i add a single lib32-* package to my image, building the sdk fails Nov 27 21:20:01 package.bbclass:PKGD = "${WORKDIR}/package" Nov 27 21:20:08 multilib support seems to be in bad shape, at least for my use case Nov 27 21:42:03 rburton: so why, if i set ${BINCONFIG_BLOB} to my wx-config symlink target, which is in /usr/lib/wx/..., doesn't it find it? Nov 27 21:42:56 and i have FILES_${PN}-dev += "${libdir}/wx" Nov 27 21:44:40 oh wait. Nov 27 21:44:46