**** BEGIN LOGGING AT Fri Mar 22 02:59:57 2019 Mar 22 06:26:04 I have a problem with using meson in yocto Mar 22 06:26:45 if the build option is a arrays, I need to use the comma to separate its value Mar 22 06:27:35 but I can't do that at PACKAGECONFIG, it would be regarded as next option for PACKAGECONFIG Mar 22 06:27:45 any idea to avoid this problem? Mar 22 08:32:35 stdint: check mesa.inc and how --with-dri-drivers or --with-vulkan-drivers are managed. Mar 22 08:33:24 basically you use an additional variable for the 'arrays'. Mar 22 08:33:31 ndec, I see I will thank you Mar 22 08:34:13 PACKAGECONFIG is first parsed before variables it contains are expanded Mar 22 08:35:13 ndec, thank you Mar 22 09:02:57 Hi, poky/meta/recipes-core/packagegroups/packagegroup-base.bb contains e.g. the line ${@bb.utils.contains("MACHINE_FEATURES", "phone", "packagegroup-base-phone", "", d)}... and later RDEPENDS_packagegroup-base-phone = " ofono". Mar 22 09:02:59 My question is: "phone", "packagegroup-base-phone" and "ofono" - what is each one called in yocto-language? Is it a package or packet or something? I'm not familiar with the proper category naming. Mar 22 10:11:48 What is the difference between "phone" and "ofono"? Mar 22 10:12:57 Is "phone" called "a group of packages" and "ofono" is called "a package"? How is it called? Mar 22 10:13:25 ...in yocto nomenclature Mar 22 10:15:06 fbre: ofono is a packages, unrelated to the yocto project. its just the name of the software. Mar 22 10:15:25 fbre: see: https://01.org/ofono Mar 22 10:16:22 fbre: the line that you pasted basically says: "if MACHINE_FEATURES contains the string 'phone', then add packagegroup-base-phone to packagegroup-base" Mar 22 10:16:40 fbre: and the latter just says that packagegroup-base-phone includes ofono Mar 22 10:16:49 Hi guys. How I can add an 'xrender' dependency to ny qt5 recipe? Because Qt5 requires 'xrender', but I don't know where I need to add this xrender.. Mar 22 10:18:38 kuzulis: do you actually mean "libxrender"? or rather "xrandr"? Mar 22 10:19:32 (yet, in both cases, you should be fine to add it to your DEPENDS respective RDEPENDS) Mar 22 10:19:46 LetoThe2nd: Seems it is libxrender.. Mar 22 10:20:04 LetoThe2nd: Thanx!! How do you call in yocto something like "packagegroup-base"? Is it a "package family"? Mar 22 10:20:33 fbre: we call it a "packagegroup" (SURPRISE!) Mar 22 10:20:43 kuzulis: well then, add libxrender. Mar 22 10:20:46 uhmm OK :) Mar 22 10:21:33 LetoThe2nd: And how do we call something like that "phone"? That is what I actually configure in my .conf file Mar 22 10:22:02 fbre: its a MACHINE_FEATURE Mar 22 10:22:52 ah OK, and the other ones are DISTRO_FEATURE then. OK, thanx. I was not sure about the proper classifier naming Mar 22 10:25:50 The difficult thing is, https://layers.openembedded.org/layerindex/branch/sumo/layers/ lists just the names of packages but not how they are called as MACHINE_FEATUREs or DISTRO_FEATUREs. So it's hard to track down what string I have to remove with DISTRO_FEATURE_remove to prevent certain packages in my own distro. Mar 22 10:26:46 First, I tried this "DISTRO_FEATURE_remove = "ofono" and failed. :-( Mar 22 10:28:10 The documentation does not clearly describe how I get from "ofono" to "phone" Mar 22 10:29:16 fbre: usually i just do bitbake -g $MYIMAGE, and then inspect package-depends.dot Mar 22 10:29:40 there is some oe-scriptwhatevermagicthingy to aid in this too, but i just can't get its name into my head. Mar 22 10:30:14 LetoThe2nd: Oh I haven't known that package-depends.dot! Thanx. Having a look now... Mar 22 10:31:21 LetoThe2nd: Hmm.. I have added: RDEPENDS_${PN}_append = "libxrandr" to my packagegroup-core-x11-base.bbappend, but now, the image recipe fails with: ERROR: Nothing RPROVIDES 'liberation-fontslibxrandr' (but /mnt/data/Yocto-miatech/yocto-miatech/sources/poky/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb RDEPENDS on or otherwise requires it) Mar 22 10:31:47 fbre: and a package usually does not directly correlate to an expression in DISTRO_FEATURES or MACHINE_FEATURES Mar 22 10:32:12 kuzulis: why do you tinker the packagegroup if your recipe depends on it? Mar 22 10:32:41 kuzulis: and adding a library to RDEPENDS is strange, as you usually already want to have it ready during compile stage. Mar 22 10:33:03 kuzulis: and, liberation font are something totally different again. Mar 22 10:33:04 LetoThe2nd: Because I is a full zero in yocto :) Mar 22 10:33:33 kuzulis: and you even mixed up things. there is "libxrender" or "xrandr" Mar 22 10:35:26 LetoThe2nd: I just don't understand, where I need to put the RDEPENDS and in what of a content? Should it looks like: RDEPENDS_${PN}_append = "libxrandr" ? Mar 22 10:35:46 kuzulis: no. Mar 22 10:36:20 you have some qt application, probably. and if that application needs something, then add DEPENDS = "whatever" to the recipe of that application. Mar 22 10:37:01 kuzulis: seriously, do not tinker a packagegroup if you don't know what you're doing. Mar 22 10:40:20 LetoThe2nd: Just DEPENDS += "libxrandr" ? :) Mar 22 10:42:10 kuzulis: if your application needs libxrandr, then yes. Mar 22 10:42:41 LetoThe2nd: A Qt5 itself needs libxrandr for building Mar 22 10:43:21 LetoThe2nd: So, do I need just to add DEPENDS += 'libxrandr' to my qt5-base.bbappend recipe? Mar 22 10:45:42 kuzulis: i seriously doubt that you need to add it manually. Mar 22 10:45:54 LetoThe2nd: Wow, seems it does work! :) Many many thanks :) Mar 22 10:46:00 kuzulis: you are probably doing something wrong or unexpected somewhere else. Mar 22 10:47:41 LetoThe2nd: This is probably true, I am doing something wrong .. But I do not have time to figure it out ... I need to do it quickly and to forgot it .. :) Many thanks, again. Mar 22 10:50:10 *sigh* in that case, save some time for the day it blow up into your face because you just did it quick and dirty now. Mar 22 10:50:18 but, have fun. Mar 22 10:52:21 LetoThe2nd: What if I need to add this option only if a X11 is enabled? Do I need to use it like: DEPENDS[x11] += "libxrandr" ? Mar 22 10:52:33 nope. Mar 22 10:52:59 LetoThe2nd: DEPENDS_append_x11 += "libxrandr" ? Mar 22 10:53:19 LetoThe2nd: Brute force :) Mar 22 10:53:23 packagegroup-base contains a lot of examples on how to evaluate DISTRO_FEATURES or MACHINE_FEATURES and modify depends accordingly. Mar 22 10:53:32 go read there. Mar 22 10:53:43 LetoThe2nd: Ohh, ok, many thanks. Mar 22 10:58:53 New news from stackoverflow: using require in layer.conf in yocto Mar 22 11:32:44 stupid noob question, i want to have /tmp have its own tmpfs (syslog tends to fill up our /var/log). I wonder how I can best override initscripts/volatile (that creates the symlink from /tmp to /var/tmp) and potentially fs-perms.txt (which links from /var/tmp to /var/volatile/tmp) Mar 22 11:33:07 i couldn't really find too much with my google fu except FILESYSTEM_PERMS_TABLE variable, which only does the second part of what i need Mar 22 11:36:19 m4nu3l: by default /var/log should be volatile anyways (see https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-VOLATILE_LOG_DIR) Mar 22 11:36:41 m4nu3l: so if it is not in your case, try to find out what sets VOLATILE_LOG_DIR to "no" Mar 22 11:39:04 it is volatile Mar 22 11:39:14 we limited it to 20 MB because a misbehaving program would quickly fill it up Mar 22 11:39:32 (and kill the system since it would take half the RAM) Mar 22 11:39:54 but now we run into issues where shell scripts fail because /var/volatile/tmp is full and can't create here files Mar 22 11:40:14 do i want both /var/log and /tmp to be volatile, but separate partitions Mar 22 11:40:15 m4nu3l: hum ok, so want two separate tmpfs. guess you have to dig deeper in base-files.bb then Mar 22 11:40:32 no specific idea, sorry. Mar 22 11:40:34 ok, so no "configurable" way Mar 22 11:40:41 at least that you know of Mar 22 11:40:43 none that i would be aware of. Mar 22 11:40:44 thx Mar 22 11:40:52 won't be too bad i'm sure Mar 22 11:44:25 hey, the pulseaudio recipe inherits from the useradd class, which tries to run the command `groupmems --root /mnt/build/tmp/work/aarch64-poky-linux/pulseaudio/11.1-r0/recipe-sysroot -g audio -a root -g audio -a root`. That's apparently an invalid command, because it prints the usage information, and pulseaudio's do_prepare_recipe_sysroot fails. Wh Mar 22 11:44:25 at's going on? Mar 22 12:11:36 mort: My yocto does not contain a file "recipe-sysroot". Where do you find it in your yocto directory tree "source"? Mar 22 12:11:55 sorry "sources" Mar 22 12:12:25 fbre: bitbake creates the recipe-sysroot folder when building a recipe Mar 22 12:14:19 and what is pulseaudio recipe then? What is the path and filename in the sources tree? Mar 22 12:14:51 fbre: it's in poky/meta/recipes-multimedia/pulseaudio Mar 22 12:17:10 groupmem is executed by useradd_base.bbclass from useradd.bbclass, which pulseaudio_11.1.bb inherits from Mar 22 12:17:16 groupmems* Mar 22 12:18:05 mort: I've got the yocto version "sumo" and there is not useradd* file Mar 22 12:19:59 I'm on poky commit 29f65bda6d2c9fea4adb125c4857ee64f9312b9f, which is sumo Mar 22 12:21:29 mort: https://pasteboard.co/I6AZ22w.png Mar 22 12:22:10 fbre: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/useradd.bbclass?id=29f65bda6d2c9fea4adb125c4857ee64f9312b9f Mar 22 12:23:42 mort: you said poky/meta/recipes-multimedia/pulseaudio Mar 22 12:24:04 mort: but this is poky/tree/meta/classes/useradd.bbclass Mar 22 12:24:04 yeah, that's where the failing recipe is, but as I said, that recipe inherits from useradd.bbclass Mar 22 12:25:42 when doing the `perform_groupadd "$SYSROOT" "$OPT $opts"` on line 57 of useradd.bbclass, it seems like the opts variable contains " -g audio -a root -g audio -a root", which seems wrong Mar 22 12:29:56 mort: I would hack it and comment out that line Mar 22 12:30:43 I don't understand where GROUPADD_PARAM is getting set to anything, the pulseaudio recipe certainly isn't setting it to "-g audio -a root -g audio -a root", I can't find anything related in my config, and this build system doesn't exactly have the most debuggable language Mar 22 12:31:25 mort: it seems to me they want to add the user "root" to the group "audio". Mar 22 12:31:35 yeah, but why is that in there twice? Mar 22 12:32:04 it's presumably somewhat important for the user root to be in the group audio, so just commenting it out seems like it would just subtly break our system Mar 22 12:33:17 sorry, it seems to be the perform_groupmems on line 89 which does "-g audio -a root -g audio -a root", not the identical perform_groupmems in the identically looking block on line 57 Mar 22 12:34:24 mort: you could do: EXTRA_USERS_PARAM = "useradd -P mom123 -G audio root" Mar 22 12:35:04 this should add root to audio Mar 22 12:35:33 in recipes-core/images/core-image-minimal.bbappend Mar 22 12:35:46 but this shouldn't be broken in the first place, and I'm very not comfortable just going around and patching core yocto files just because something seems to be broken Mar 22 12:36:26 hmm yes. I'm not a yocto guru, and that would just be a hack/workaround Mar 22 12:36:29 hello, am a novice yocto user. I am trying to use SSTATE_MIRRORS pointing to http://sstate.yoctoproject.org - is there a way to tell bitbake to fail it doesn't find a package from yocto. i.e., I want to make sure everything is fetched and not built Mar 22 12:37:14 mort: I don't use audio of sumo, so I don't run into your problem :) Mar 22 12:37:29 sorry, can't help further Mar 22 12:37:37 Chaser: and what would be the rationale behind that? Mar 22 12:37:43 I'm not too comfortable with how often yocto seems to just randomly not work, last week I tried upgrading to thud and abandoned that project because thud just literally broke the git submodule fetcher, and now the useradd class and/or pulseaudio recipe just doesn't work Mar 22 12:38:33 LetoThe2nd: to see what packages are missing from shared state. I want to setup private sstate mirror and I want my local builds to fail if it doesn't find pre built package. Mar 22 12:40:10 Chaser: hm. not sure if that approach really works. but might indeed be. Mar 22 12:41:09 LetoThe2nd: cool Mar 22 12:44:39 mort: You mentioned the git commit of your poky. Do you use the repo tool for sync'ing to git? Mar 22 12:45:23 fbre: no, wouldn't the regular git commands be enough? Mar 22 12:46:32 mort: I just ask because I use the repo tool and I can tell you which git commit I use. I don't have build problems, even if I build everything. Mar 22 12:53:05 mort: my poky git revision is 64a257fa22126c4a40ff7e03424a404e360ebe1e Mar 22 12:53:33 mort: everything works there... (hopefully ;-) ) Mar 22 12:55:23 mort: at least compare that with your git revision Mar 22 12:55:42 maybe the diff is small Mar 22 13:16:39 it seems like the diff is pretty big, my version is from april and yours is from september and a lot happened in those 6 months it seems Mar 22 13:26:33 mort: this git version I use is what my eval board vendor advises Mar 22 13:26:42 mort: so I think it's a stable one Mar 22 14:16:51 RP: little update regarding the lttng-tools ptest stuff, we fidlled with musl a bit before sending patches and turn out musl is having some spuradic issue in getgrnam (will post the backtraces on the musl mailing list and CC you), this lead me to do a cleanup in the tests suite to ensure that we run only test that are not dependent on lttng-ust... slowly getting there. Mar 22 14:17:18 spuradic -> sporadic... Mar 22 14:29:33 psrcode: ah, interesting. The one that is really bothering me is the core-image-sato-sdk hang :/ Mar 22 14:30:48 RP: this is fixed, it is caused by this: https://lists.lttng.org/pipermail/lttng-dev/2019-March/028604.html Mar 22 14:31:58 psrcode: ah, great. So we'll get that fix when we upgrade lttng-tools? Mar 22 14:33:10 it is not upstream yet but I plan on sending you a recipe update including all the necesseary fixes, we are currently putting a lot of effort on the 2.11 release so all other activity (bugfix/backport) is kind of halted for now. Mar 22 14:34:37 psrcode: sounds good, I'd be happy to get that fixed with a patch until its upstream. I know you'll work on that when appropriate (I know all about release challenges!) Mar 22 14:59:53 Isn't FILES_${PN} += "${libdir}/*.so" what you need to put a /usr/lib/libmylib.so into mypkg? I'm getting QA error on said lib into -dev, but I'm not getting the FILES_${PN} statement to take hold. What could I be missing? Mar 22 15:08:47 sveinse: not enough, no, ${PN}-dev is grabbing it first, as we don't normally package the symlink .so in the mian package Mar 22 15:09:02 FILES_${PN} += "${libdir}/*.so" Mar 22 15:09:02 FILES_SOLIBSDEV = "" Mar 22 15:09:07 that's how i usually do it Mar 22 15:09:19 package it in ${PN}, and don't package it in -dev, respectively Mar 22 15:09:41 remember that the first package in PACKAGES to grab a given file gets it, so order in PACKAGES matters Mar 22 15:10:29 Yeah, this is this discussion about .so not being the actual file, just the symlink and this source puts the binaries in .so. Thanks kergoth Mar 22 15:10:35 np Mar 22 15:11:14 It's so nice where there is multiple practices out there :D (or the one half dont care how it is implemented) Mar 22 15:11:50 heh, welcome to oe/yocto :) where there are 47 ways to do any given task Mar 22 15:12:00 natural consequence of the flexibility, really Mar 22 15:12:06 True :D Mar 22 15:12:32 You're not a yocto developer unless you have mastered grep and find! Mar 22 15:12:46 ideally need better linting tools to help catching less than ideal approaches, but that's not always easy to do Mar 22 15:14:12 Are there any mechanisms for debugging the package selector? as a specific example Mar 22 15:15:16 you'd need to elaborate. if you mean what binary packages from deploy get installed into the image, after the recipes are built, that depends on the package manager you're using, as we just construct the feeds and let them install them Mar 22 15:15:40 if you mean bitbake's selection of the recipe to build for a given provider, that's a different thing, and -d can add info a bout that, though along iwth a ton of unrelated stuff Mar 22 15:17:27 Well, the cause for my FILES_ rule to not work is because the -dev package picked it first. I would love to have a verbose log that sais "found file x: Placed into y-dev because of rule 'y'" or something similar. With it I would have seen that -dev picked up my file and why Mar 22 15:18:22 package split is the more correct term Mar 22 15:18:51 hmm, check package.bbclass, that's what does it Mar 22 15:18:57 might be something in there, message wise Mar 22 15:19:03 see also the log file for do_package, perhaps Mar 22 15:19:27 kergoth: thanks, I'll check package.bbclass Mar 22 15:59:56 New news from stackoverflow: Qt - Module "QtQuick.Controls" is not installed Mar 22 16:21:25 sveinse: top hint is to always remember that FILES are used in the order of PACKAGES Mar 22 16:22:11 sveinse: of course, oe-pkgdata-util will show you what files are in what package. then it's usually fairly simple to figure out *why*. bitbake recipe -e, search for FILES_{the package with files you don't expect in}, see why and where the value is set to what it is Mar 22 16:22:52 indeed Mar 22 17:28:59 RP, armpit rburton Maintenance reboots complete on everything except arm and perf machines. We should be set to queue up builds. Mar 22 17:35:32 halstead: thanks! Mar 22 18:39:02 All done with the rest. Mar 22 18:39:31 armin: Are you around? Mar 22 18:39:54 err, armpit :) Mar 22 19:13:54 Are there any documented standard of naming "lib*.so.X" and symlink "lib*.so" -> "lib*.so.X" anywhere? Or is this just defacto standard and policy in OE? Mar 22 19:14:26 it's not an oe convention, it's a linux one Mar 22 19:14:31 not just linux, either Mar 22 19:15:00 even my mac sets SONAME to include the version and then symlinks without the suffix so ld can find it Mar 22 19:15:01 kergoth: yeah, just wondering if its documented anywhere. Because some tools does the oposite. Qt is a notable one Mar 22 19:15:04 same thing Mar 22 19:15:35 the filename should always match the SONAME, and then any link, if necessary, is to ensure the linker can find it despite the name not ending in .so Mar 22 19:15:48 but conventions for how to set soname, that i'm not certain of Mar 22 19:15:50 not sure Mar 22 19:16:35 Well, Qt does not adhere to this practice or standard. So of cource our Qt devs require proof that this is wrong Mar 22 19:18:07 https://en.wikipedia.org/wiki/Soname http://man7.org/conf/lca2006/shared_libraries/slide6.html http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html Mar 22 19:18:15 not sure where it comes from historically Mar 22 19:19:22 Yeah, was reading the latter one too Mar 22 19:22:25 i know libtool enforces the convention, but not sure where it originated. apparently freebsd differs, or differed? Mar 22 19:22:56 * sveinse logging into my freeNAS server now to check Mar 22 19:23:45 *.so symlink to versioned .so.X files Mar 22 19:24:00 ah, good to know Mar 22 19:27:58 sveinse: where does Qt differ from the rest? Mar 22 19:27:59 objdump -x /usr/lib64/libQt5Gui.so.5 | grep SONAME SONAME libQt5Gui.so.5 Mar 22 19:29:41 root@qemux86:~# ls -lah /usr/lib/libQt5Gui.so.5* Mar 22 19:29:41 lrwxrwxrwx 1 root root 19 Mar 21 19:53 /usr/lib/libQt5Gui.so.5 -> libQt5Gui.so.5.11.3 Mar 22 19:29:44 lrwxrwxrwx 1 root root 19 Mar 21 19:53 /usr/lib/libQt5Gui.so.5.11 -> libQt5Gui.so.5.11.3 Mar 22 19:29:47 -rwxr-xr-x 1 root root 6.6M Mar 21 19:52 /usr/lib/libQt5Gui.so.5.11.3 Mar 22 19:29:50 root@qemux86:~# objdump -x /usr/lib/libQt5Gui.so.5.11.3 | grep SONAME SONAME libQt5Gui.so.5 Mar 22 19:31:47 Shared Libraries in SunOS, published 1987, section 4.3.5. Version Management of .so’s mentions the version suffix to the .so, including major and minor versions, though not the symlinking directly, the section on -Bdynamic and -l mentions the -l name not including the suffix, so it implies something has to resolve the mismatch, whether that's a link or gcc or ld itself isn't clear Mar 22 19:32:03 tried to find Shared Libraries on UNIX System V, but can't seem to locate the paper so far Mar 22 19:32:45 so anyone writing a project with a .so with an soname lacking a version suffix isn't even up to date with 1987 conventions ;) Mar 22 19:33:57 JaMa: you know what? I'm sorry, I'm wrong. In the later Qt5 (5.11 at least) this is now correct. At some point in the past, they changed it. The .so.x.y.z (and the other "lesser") pointed to .so. But now, it is indeed correct where the .so points to the .so.x.y.z as you say and as it should. Mar 22 19:34:50 sveinse: interesting, in all my builds since Qt 3 I think it was correct Mar 22 19:35:34 I remember it clearly, because getting our own Qt app in recipe, involved some .so trixing to get it past the QA tests. Mar 22 19:35:50 Let me check back on older released. We've got artifacts from the first product release in 2012 Mar 22 19:36:25 I've checked image with 5.6.3 and the same Mar 22 19:36:45 sveinse: were you using meta-qt5 for that product? Mar 22 19:37:37 I've started meta-qt5 at the end of 2012 Mar 22 19:37:48 What branch would be best to use for rpi3 B with adafruit 3,5' display? Mar 22 19:37:59 I don't have any image qith old qt4 or qt3 handy to check Mar 22 19:38:27 no, we changed to yocto in 2017 Mar 22 19:38:52 maybe it was your build system messing with the filenames, not Qt itself :) Mar 22 19:39:05 I'm asking becouse I'm getting different results with krogoth,morty and master and i want to fix the "right" one Mar 22 19:39:38 JaMa: perhaps. At least with a different qmake config. Mar 22 19:39:43 willie2: these are different releases, see https://wiki.yoctoproject.org/wiki/Releases Mar 22 19:40:28 either of them should work to some extend, but if you need to fix something then you should start with master Mar 22 19:40:39 and then it can be backported to stable branches if needed Mar 22 19:41:23 Jama: Okay, Well i can build stuff with krogoth but display settings are not supported as far as iknow Mar 22 19:42:15 What would be the ideal branch to put some time into? Mar 22 19:42:16 krogoth is the oldest from the 3, IIRC it doesn't even have proper support for 3-B Mar 22 19:42:22 willie2: master Mar 22 19:42:39 alright :) Mar 22 19:43:38 and if you don't want other layers to change under your hands too much, then use thud Mar 22 19:44:02 but then you'll still need to test and submit on master, before it gets accepted to thud Mar 22 19:44:04 JaMa, I found one in 4.8.5: ./usr/lib/libQtCore.so.4 -> libQtCore.so.4.8.5, and ./usr/lib/libQtCore.so.4.8 -> libQtCore.so.4.8.5 , and no libQtCore.so (symlink). Yet, not quite what I claimed thou Mar 22 19:44:45 sveinse: that's correct, libQtCore.so should be only in -dev package, so it isn't normally installed Mar 22 19:45:22 Except this was from a tgz containing everyting the Qt installer installed Mar 22 19:46:37 I'm wondinger if this was I was mistaking this with. We had some problems with this, as you had to specify so version when loading the lib in lack of the .so file Mar 22 19:47:37 I have to yield to be honest, I am very uncertain about all this, so I'm withdrawing my claim of Qt not doing this right. At least it is correct in the novel images Mar 22 19:47:58 sorry guys Mar 22 20:44:15 JPEW, I am now Mar 22 21:06:48 armpit: Not trying to cause trouble, but is there an estimate on when thud will get updated from thud-next? Our SDK builds are broken without the target-sdk-provides-dummy changes :( Mar 22 21:07:11 Trying to decide if I should wait or cherry-pick them locally Mar 22 21:14:36 JPEW, I don't. I need to separate my poky changes into there corresponding repos. I was hoping to sort all that out over the weekend Mar 22 21:15:07 armpit: That's fair. Thanks! Mar 22 23:17:40 RP: hey uh, does wic have some option to pad a rawcopy image with 0xff instead of 0x00 ? Mar 23 00:35:58 Marex: I honestly have no idea Mar 23 00:48:53 RP: :) Mar 23 00:48:59 RP: nevermind then Mar 23 00:49:15 RP: I think wic might not be the right tool for the job in this case even Mar 23 01:07:47 RP, go to bed Mar 23 01:45:14 JPEW, sent pull requests for thud, its up to RP to merge now Mar 23 02:18:59 * armpit finally sumo is done **** ENDING LOGGING AT Sat Mar 23 03:00:16 2019