**** BEGIN LOGGING AT Fri Dec 13 02:59:58 2019 Dec 13 08:02:36 I would like two build a cmake project with CMAKE_BUILD_TYPE either set to Debug or Release depending on the Image i build. I've tried something like APP_BUILDTYPE = "Debug" set in debug-image.bb and in the Recipe i set EXTRA_OECMAKE += " -DCMAKE_BUILD_TYPE=${APP_BUILDTYPE}". This does not work CMAKE_BUILD_TYPE was not set as i can see using cmake Dec 13 08:02:37 message. What is the bitbake way to achieve this? Dec 13 08:19:48 Domin1k: you cannot affect how a package is built depending on image recipe Dec 13 08:21:05 When the package is built, it knows nothing about the image(s) it might end up at a later stage. Dec 13 08:21:15 Domin1k: what you are taking about is something to be set in DISTRO Dec 13 08:23:41 And depending on your usecase, maybe RelWithDebInfo will be enough and they you'll add the -dbg package to the image where you want debug Dec 13 08:24:20 But if you really want a debug build look into what LetoThe2nd said Dec 13 08:32:30 LetoThe2nd: so you mean defining a debug.distro with DISTRO_FEATURES_append = " app_debug" in debug_distro.conf and setting EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'app_debug', 'DEBUG', 'RELEASE', d)}" within my recipe ? Dec 13 08:32:51 Domin1k: bingo Dec 13 08:33:27 Domin1k: congrats, you're the first who ever had that use case and understood on first try instead of ranting "but i just want to" Dec 13 08:34:05 No in my usecase the "Debug" Buildtype is more than a Release with debug info. It's more a Dev-Version of the app Dec 13 08:34:39 LetoThe2nd: Thanks! :] Dec 13 08:35:44 yeah, i totally understand. and yes, its a common usecase. people just fail to see that this is actually a distro switch (even philosophically correct, as it changes the image ABI/API), and keep on complaining "i just want that it works the way i want it to." Dec 13 08:43:16 letothe2nd: Hmm, interesting. We have that use case too, but we create two separate images from it instead Dec 13 08:44:01 Of course, our "dev" image is more like production + a bunch of extra packets and kernel trace options :P Dec 13 08:44:35 Learn new things every day! ^^ Dec 13 08:44:58 wertigon: it depends certainly on the specific use case. generally, its like this: if you just want extra stuff installed, derived image. if you want to change/add debug flags to various bits and pieces, then distro. often its a combination of both. Dec 13 08:45:55 Yeah, makes sense. So far we have a single unified distro but this might change soon as the product lineup that use spark grows Dec 13 08:46:49 spark is our project name for the Linux distro Dec 13 08:48:08 guessed that much Dec 13 11:09:31 how do you replace busybox shell with bash? Is there a note about that? Dec 13 11:18:11 mckoan: there was some discussion lately about how to get rid of busybox altogether. or do you want to keep it, and just use bash the terminal itself? Dec 13 11:20:20 LetoThe2nd: both may be interesting, however ATM I need to use bash only Dec 13 11:20:40 LetoThe2nd: do you have any link abot such discussions? Dec 13 11:20:40 mckoan: and just adding it to the image doesn't do the trick? for us that works nicely. Dec 13 11:20:53 LetoThe2nd: I try Dec 13 11:33:39 RP: erm, pseudo-native won't build for me Dec 13 11:35:12 is http://downloads.yoctoproject.org/releases/opkg/ down? Dec 13 11:36:28 https://downforeveryoneorjustme.com/downloads.yoctoproject.org Dec 13 11:37:07 oops Dec 13 11:37:28 halstead: downloads.yp appears to be down Dec 13 11:38:05 LetoThe2nd: yep, sorry for the noise Dec 13 11:38:37 can anyone recommend a mirror i could use? Dec 13 11:38:46 mckoan: np. easy problems are the best problems :) Dec 13 11:39:42 rburton: on it. Dec 13 11:46:16 rburton, It appears that whole data center is offline at the moment. Trying to find out more. Dec 13 11:47:12 milloni: what halstead said. curious how you've been using yocto a while but don't have a copy of opkg.tar.gz in your DL_DIR! Dec 13 11:47:25 oe probably has another mirror Dec 13 11:48:36 http://sources.openembedded.org but doesn't have 0.4.1 if that's what you're after Dec 13 11:49:17 rburton: i dont know if you want to know: our CI builds everything from scratch every time because we couldn't get caching working Dec 13 11:50:10 milloni: you couldn't get it to have a persistant DL_DIR? that must be very boring Dec 13 11:50:33 some of the clones are sooooo sloooowww Dec 13 11:50:46 i wasnt around at the time, and now everything is on fire so we've got more important things to do Dec 13 11:50:57 milloni, You can grab it from http://mirrors.kernel.org/yocto/opkg/ for now. Dec 13 11:51:06 thanks Dec 13 11:51:17 kanavin: so i just sucked up your entire branch and picked up a few broken bits. what branch corresponds to the latest patchbomb? Dec 13 11:51:41 rburton, akanavin/package-version-updates Dec 13 11:52:31 right Dec 13 11:52:31 rburton, this branch is frequently forced pushed to, beware Dec 13 11:52:36 fwiw, acl/attr wip breaks pseudo-native Dec 13 11:53:17 rburton, I think I have a later version of that? Dec 13 11:53:31 and no breakages observed here :-/ Dec 13 11:54:28 probably host specific? Dec 13 11:55:23 probably, I am on ubuntu 18.04 Dec 13 12:18:09 hello I have read presentation when external toolchain can be used to build yocto packages, I have such aarch64 toolchain from vendor of SoC Dec 13 12:18:31 question is how to integrate it to yocto? I think I need to create something like meta-linaro with toolchain stuff? Dec 13 12:18:52 I cannot use yocto toolchain as atf + kernrl won't boot when compiled with zeus 9.2 gcc Dec 13 12:18:57 any other ideas? Dec 13 12:20:33 hi, is there a way to add extra disk space to only the ext4 image and not to all other images ? Dec 13 12:21:12 you can easily add more space to just a specific image name, but not type Dec 13 12:22:28 rburton: thx, ok, but not from yocto direct Dec 13 12:23:06 just set IMAGE_ROOTFS_EXTRA_SPACE in the right place Dec 13 12:23:44 ok, thx Dec 13 13:03:17 rburton: did you get it working? Dec 13 13:09:30 ndec: ping - can you maybe put the announce on twitter? Dec 13 13:24:05 hi LetoThe2nd, ouch.. i thought it was done after you sent your email.. i will do it! Dec 13 13:25:07 ndec: thanks. Dec 13 13:26:10 ndec: sidenote, we have accumulated way over 6k view on YT alone by now. Dec 13 13:26:43 nice! Dec 13 13:28:32 LetoThe2nd: is it 4PM or 5PM? Dec 13 13:28:44 your email says 4PM, but it is usually at 5Pm, no? Dec 13 13:29:29 ndec: even more ouch. please announce 4:30pm berlin time. Dec 13 13:29:44 i have to shuffle around a bit, as my usual streaming place is not available currently Dec 13 13:29:51 ah, ok. Dec 13 13:32:28 ndec: thanks a lot! Dec 13 13:35:06 LetoThe2nd: np! Dec 13 13:42:36 kanavin: doesn't blacklisting nss on armv7 cause a lot of fallout? Dec 13 14:10:36 Hey does anyone know if http://downloads.yoctoproject.org/releases/ id down. My build is failing when attempting to fetch opkg-0.4.1.tar.gz. Dec 13 14:10:50 sorry is down Dec 13 14:11:25 kukela_cd: yes, we're trying to get it sorted Dec 13 14:11:46 kukela_cd, Yes the data center has a router down. Dec 13 14:11:58 Okay thanks. I just wanted to be sure before i started digging into things Dec 13 14:12:29 kukela_cd, That file is also available at http://mirrors.kernel.org/yocto/opkg/ Dec 13 14:18:17 kukela_cd: top tip is to ensure that your DL_DIR is shared and cached locally Dec 13 14:20:40 yeah that is true Dec 13 14:21:02 how do i use the mirror at http://mirrors.kernel.org/yocto/ for everything? Dec 13 14:21:25 thats not a full mirror Dec 13 14:21:46 yeah but i hope it will at least have the things that originally come from downloads.yp Dec 13 14:22:01 it seems to mirror downloads.yp/releases Dec 13 14:22:11 look up MIRRORS in the manual Dec 13 14:23:27 trying that now Dec 13 14:23:55 if i just add http://mirrors.kernel.org/yocto/ will it go into each subdirectory looking for packages? Dec 13 14:25:20 note how MIRRORS is pairs of urls Dec 13 14:25:32 map one to the other Dec 13 14:27:20 dv_: am i imagining it, or did you have patches to move gstreamer to meson? Dec 13 14:27:35 yep Dec 13 14:27:38 i'm trying this Dec 13 14:27:41 http://.*/.* http://mirrors.kernel.org/yocto/ \n \ Dec 13 14:27:51 and a similar pattern for https, ftp ,etc Dec 13 14:28:12 but that's where my understanding of the syntax ends Dec 13 14:28:36 so for example, opkg needs Dec 13 14:28:38 SRC_URI = "http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz Dec 13 14:29:14 try 'http://downloads.yoctoproject.org/ https://mirrors.kernel.org/yocto/' Dec 13 14:29:28 oh, /releases/ on the first bit Dec 13 14:29:49 ok thanks Dec 13 14:50:26 rburton: I'll try to rebase them tomorrow Dec 13 14:50:30 and send them to the mailing list Dec 13 14:50:37 dv_: awesome Dec 13 14:50:47 there are some leftover unclear issues though Dec 13 14:50:58 dv_: wrote a little qa test to tell me when recipes use autotools but have a meson file, and gstreamer was the big obvious one Dec 13 14:52:28 rburton: for the todos, see https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg129383.html Dec 13 14:52:35 yeah, I can imagine Dec 13 14:55:18 ok Dec 13 14:55:31 well rebase and post as a WIP and we can discuss further Dec 13 14:55:32 thanks! Dec 13 15:14:21 if i give bitbake a list of recipes, bitbake r1 r2 r3 ... RN, does it build them in order? Dec 13 15:14:41 yates: no Dec 13 15:15:19 undefined order unless there are dependencies amongst them Dec 13 15:16:02 i see. ok thank you Dec 13 15:16:10 RP: rpm will no longer build, or mozjs. I don't think there's much else? Dec 13 15:16:35 kergoth: probably he means on command line Dec 13 15:17:03 i know, but he didn't specify if any of those specified on the commandline depend on one another. probably not, but unless he read the recipes.. Dec 13 15:17:04 :) Dec 13 15:17:31 kanavin: rpm is probably kind of important though :( Dec 13 15:17:58 RP: rburton has a patch to switch rpm to gnutls Dec 13 15:21:01 kanavin: which has issues iirc :) Dec 13 15:21:12 but seriously, that would be a good move Dec 13 15:21:19 RP: also, armv7a only needs the disabling. qemuarm for instance still works fine. Dec 13 15:21:26 * RP thinks he's found a way to fix the performance issue when rehashing Dec 13 15:21:47 kanavin: it does sound rather like there is a bug in rpm Dec 13 15:37:17 RP: rpm also has an option use openssl, I think that should work just as well Dec 13 15:37:32 there are no other users of nss in core at least Dec 13 15:37:46 kanavin: right, I'm fine with removing nss Dec 13 15:38:22 RP: but if we want polkit in core, it needs mozjs, which needs nss :-/ Dec 13 15:38:35 kanavin: gah! :) Dec 13 15:39:00 (also mozjs needs python2-native !) Dec 13 15:39:12 ugh Dec 13 15:39:38 kanavin: well, python2 isn't coming back... Dec 13 15:40:23 RP, yes, I have a patch to remove the recipes. Just waiting for some kind of action on copying them to a different layer. Dec 13 15:40:45 kanavin: I'm just trying to get M1 sorted before I think about that :) Dec 13 15:40:56 we've done the hard part for core Dec 13 15:41:13 RP, for sure Dec 13 15:43:20 Is downloads.yoctoprojects.org down for the counts? Dec 13 15:43:30 downloads.yoctoproject.org Dec 13 15:46:48 sveinse: yes, its being worked on Dec 13 15:47:29 RP, ok thanks. Will there come a notification here when it is complete? Dec 13 15:47:53 sveinse: when I say worked on, I mean people are aware of the problem and working to fix it, it wasn't scheduled Dec 13 15:48:06 sveinse: I'm sure halstead will mention something, yes Dec 13 15:48:34 RP: ok, best of luck getting it up Dec 13 15:56:14 nice, pydeps (https://github.com/thebjorn/pydeps) works with graph-easy, figured it'd be easy enough. https://gist.github.com/5a6e8e85fa53097a01e886a677b0bfb7 Dec 13 15:56:24 shows the cycles between our bitbake modules in an ascii graph Dec 13 15:57:01 oh right, forgot it can use unicode boxart instead. https://gist.github.com/385fc98d3e9a8018d56d6003307da3b6 Dec 13 16:02:50 hi, i'm trying to backport some go recipes and there's a helper python function (go_map_arm) that seems to be failing, and when i print out the value of the arguments in that function i get things like "go_map_arm a=${TUNE_ARCH} f=${TUNE_FEATURES_tune-${DEFAULTTUNE}}" but not an expanded form Dec 13 16:03:05 kergoth: all a bit circular :/ Dec 13 16:03:15 yeah, i suspected as much :)' Dec 13 16:03:25 not a huge deal, just something to think about refactoring someday.. Dec 13 16:03:28 kergoth: sadly so did I Dec 13 16:03:55 i'd really like the parsing to provide a nicer api at some point. it should be easy to parse an arbitrary string, not just files, for example Dec 13 16:04:12 would have to have a break from fighting fires to do something like that htough :) Dec 13 16:05:32 guido's articles on PEG parsing lately are rather interseting Dec 13 16:05:38 hi folks, i want to install a bunch of *ipk into another dir, like "opkg -o /myNewRootfs install *.ipk" but that fails if a package in the set of ipk is already installed in / (because resolution of -o seems to leak to / as well)... maybe i use it wrong? Dec 13 16:05:56 kergoth: right. My big worry is performance too :/ We have some real problems in various parts of the code Dec 13 16:06:11 idea is to install a whole second installation into /NewRootfs Dec 13 16:06:32 Piraty: you should really turn it into a package feed with opkg-utils, add it to your opkg.conf, and install them by name Dec 13 16:06:38 then it'd also use the dependencies Dec 13 16:06:59 opkg can use local package feeds Dec 13 16:07:15 that'd be my suggestion, anyway Dec 13 16:08:24 the conflict arises because package foo is to be installed which matches the same version of foo that is already installed in / (which is expected) Dec 13 16:09:14 right, and if it's a package feed installing by name, it won't reinstall it. it assumes a local file is something you really want installed as is Dec 13 16:09:15 afaict anyway Dec 13 16:09:27 using a feed should sidestep the errors and just not install those Dec 13 16:09:29 but i don't want to set --force-reinstall Dec 13 16:09:52 you assume a feed solves my problem and will instal foo into /newRoot anyway? Dec 13 16:09:57 that'd be ideal Dec 13 16:10:09 hmmm Dec 13 16:10:22 not sure, actually, just a random idea. it's odd that -o is leaking that way to begin with Dec 13 16:10:27 it should be using a separate package database Dec 13 16:10:36 adelcast: ^ can you provide info? Dec 13 16:10:38 should probably start by investigating that further if possible Dec 13 16:11:21 hmm, i guess it depends on the original purpose of offline root Dec 13 16:11:33 using a separate rootfs or just installing a subset of packages to external media Dec 13 16:11:37 not sure, actually Dec 13 16:11:39 --force-reinstall indeed does the thing i intended Dec 13 16:11:43 ah, good Dec 13 16:11:53 nevermind then :) Dec 13 16:12:03 i gotta double check still Dec 13 16:12:07 might leak even more Dec 13 16:12:15 despite there's no actual reinstall Dec 13 16:12:37 hmm i hope it doesn't write to /var but /newRoot/var for opkg db instead Dec 13 16:27:53 what does -o differ from -d then?? Dec 13 16:30:57 JPEW: hoping these tweaks to siggen and runqueue sort the performance issue (on list) Dec 13 16:31:20 RP: Ok, I'll take a look Dec 13 16:31:44 JPEW: they're kind of obvious in hindsight Dec 13 16:37:55 Hi guys! I've found a nice one I think... meta-xilinx-tools/conf/layer.conf has "INHERIT += xsct-tc" and in this bbclass, they mess with PATH. This has the effect that random recipes discover binaries in these XSCT paths that were obviously not mentionned in their DEPENDS. The fix appeared quite simple as changing the INHERIT to "INHERIT += xsct-tarball" which actually contains the eventHandler for Dec 13 16:37:57 BuildStarted, the reason for all this. It does fix the unwanted discovery of binaries, but unfortunately, I have to force build these recipes. It appears that PATH's value is not part of sstate hashes! Any clues how to fix this? Dec 13 16:52:50 JPEW: logic isn't quite right, seeing errors. Working on that... **** BEGIN LOGGING AT Fri Dec 13 17:33:43 2019 Dec 13 20:08:10 Seeing failures hitting `downloads.yoctoproject.org` - known outage? downforeveryoneorjustme agrees with me Dec 13 20:09:27 sorry - i just checked the IRC logs. my bad Dec 13 20:39:11 downloads.yoctoproject.org is back online. Dec 13 20:46:31 halstead: thank you, Michael, for your support and updates! Dec 13 20:55:26 Thanks denix. Dec 13 20:56:17 Will need to put some thought into which resources on downloads.yoctoproject.org have to stay available to keep builds running and which don't. Split into highly available bits and archives. Dec 13 20:58:43 halstead: Is there any mechanism (e.g. rsync) we could use to mirror the whole thing internally? Dec 13 20:59:49 halstead, JPEW: aren't the builds and downloads not on the same subnet? Dec 13 21:01:33 JPEW, The "whole thing" is 80TB. We can certainly have a discussion about mirrors. Dec 13 21:01:56 halstead: Ah, well... though I would ask :) Dec 13 21:02:17 denix, Different internal subnets. The same public IP range. Dec 13 21:02:59 JPEW, The important bits are much much smaller. I think mirroring those would be great. Like we do to mirrors.kernel.org. Dec 13 21:03:20 halstead: Hence the discussion about splitting it up? Dec 13 21:03:25 * halstead nods. Dec 13 21:03:31 halstead: Make sense Dec 13 21:04:07 halstead: Whats all in there now? Dec 13 21:05:15 JPEW, All the previous release artefacts. Lots of sstate. Nightly builds. Dec 13 21:06:18 halstead: I suppose the main one that causes people issues is the source code that is mirrored? Dec 13 21:07:37 JPEW, I would guess so. As well as uninative and opkg releases. Dec 13 22:59:09 halstead: thanks for fixing downloads.yp! Dec 13 23:00:38 milloni: you're welcome. Apologies for the extended downtime. There were many problems the provider should have been prepared for and weren't. Dec 13 23:23:39 JPEW, RP: pod fix rfc posted **** ENDING LOGGING AT Sat Dec 14 02:59:57 2019