**** BEGIN LOGGING AT Wed Feb 27 02:59:56 2019 Feb 27 08:42:37 good morning Feb 27 08:55:54 New news from stackoverflow: Unable to start bitbake server Feb 27 10:01:53 kanavin: https://bugs.python.org/issue36125 wasn't the response i expected Feb 27 10:02:19 kanavin: i wonder if py can be built with meson ;) Feb 27 10:53:36 rburton, must be a minor miracle cross-compiling python works for us Feb 27 10:53:48 apparently so Feb 27 10:54:35 the build itself 'just works' (as long as the architectures are completely different), it's the target vs native configuration for modules where the problems are Feb 27 11:04:15 to answer my question from yesterday myself Feb 27 11:04:15 > so `systemd` requires `systemd-container`. That's weird, first split off a subpackage but than require it during installation Feb 27 11:04:15 The answer is PACKAGECONFIG. The subpackage can be configured in our out. If it is configured in, it also needs to be installed, no choice in that phase anymore Feb 27 11:05:36 khem: thanks! Feb 27 11:06:54 u1106: don't see where the dependency on systemd-container is though Feb 27 11:07:13 u1106: or where systemd-container is in the packageconfig Feb 27 11:08:31 rburton: right, the first thing I did yesterday was to grep the recipe and I got no signigicant matches. So it must be some weird magic... Feb 27 11:08:50 u1106: there's no weird magic. where are you seeing the packageconfig? Feb 27 11:09:12 the PACKAGCONFIG option is called machined Feb 27 11:12:43 of course there is no weird magic in the true sense, I just meant the string `-container` not being matched by grep, but still "Requires: systemd-container" ending up in the packaging. Probably because the string is contained in a variable value when it happens or somthing like that Feb 27 11:14:37 what release are you using? Feb 27 11:15:51 hm i wonder if there's a library slipping into there Feb 27 11:16:20 poky$ git describe Feb 27 11:16:20 yocto-2.5.2 Feb 27 11:19:46 ah had the same thoughts yesterday. I know in rpm packaging you are not even supposed to declare dependencies on libraries, because the build tools will detect and insert the automatically (and more reliably than a packager...) Does the same hold for ipkg? I guess it must because recipes are written independently of the packaging in use, aren't they. Feb 27 11:29:32 yes Feb 27 11:34:06 meta question: Is there any advantage of using ipkg? (build-time, at runtime we don't want a package manager) I inherited it from times before I was in the company and for a long time I believed it stems from being the poky default. But I don't think that's even true, isn't rpm the poky default? Feb 27 11:34:10 u1106: Feb 27 11:34:10 DEBUG: systemd contains dangling link /lib/systemd/system/machines.target Feb 27 11:34:10 DEBUG: target found in systemd-container Feb 27 11:34:24 also /lib/systemd/system/var-lib-machines.mount Feb 27 11:34:32 move those to systemd-container, and the dependency disappears Feb 27 11:34:45 u1106: ipk is a bit faster to build Feb 27 11:34:54 if you're not uisng a package manager or multilib then i'd stick with ipk Feb 27 11:35:25 thanks, that answers the meta question :) Feb 27 11:42:16 reckon you can send a patch for the symlink problem? Feb 27 11:57:41 rburton: thought about that, but reckon I first need to reproduce it on poky master and create the patch there? What mailing list would it go to? And maybe I should first understand what dangling *link* really means. Guessing it does not mean Unix style hard or symbolic link, but something else Feb 27 11:58:01 its a dangling symlink Feb 27 11:58:06 (hard links can't dangle) Feb 27 11:58:35 it would go to openembedded-core@lists.openembedded.org Feb 27 12:03:53 hmm, there are 2 different kinds of log entires. DEBUG entries talk about "dangling link", NOTE entries talk about "dangling symlink". What is the difference? Some DEBUG entries have a matching NOTE, but others don't Feb 27 12:22:54 ok, systemd-wise this problem seems to affect *.wants links. The systemd main package seems to contain *.wants links to units contained in a subpackage. Should be technically safe to move them to the subpackage, because they cannot work in the main pacakge alone anyway. However, such change could break existing images. I someone relies on systemd-container but currently gets it installed only because of the dangling link ceating a "Requires:" in packaging Feb 27 12:22:54 their image would break. What's the openembedded/yocto policy here: Correct things that are wrong, even though the correction might break existing images or avoiding surprises for existing code? Feb 27 12:42:52 u1106, avoid surprises in stable branches, but fix things in the master Feb 27 12:43:13 ACK Feb 27 12:54:44 Hi, which tool can you advice for finding the reason for latency peaks? I measure such latency issues with my oszilloscope as I trigger a GPIO input, poll and read in in a user space test program and write back to a GPIO output in response? The time between trigger of input and measuring the response on the GPIO output is usually some microseconds but sometimes goes up to 20ms. Feb 27 12:55:08 The system is an evaluation board with yocto linux Feb 27 13:01:03 hmm, there is something in the kernel's tools directory. Doesn't seem to widely used or maintained though. I shortly used it ~3 years ago and the first think I needed to was to patch the reported resoulution, because it was obviously from a time when machines where much slower and everthing was reported as 0.01 or something like that Feb 27 13:02:35 I must admit I did not send a patch. But I assume there are also other reasons why the tool might not be so useful, I am not working with realtime requirements usually Feb 27 13:03:47 in the kernel's tools directory... (?) Feb 27 13:04:23 What is its name? Feb 27 13:04:33 I mean the name of the tool Feb 27 13:06:43 just looking, maybe it was not in the tools directory after all, but somewhere else??? A websearch just brought up https://lwn.net/Articles/266153/ but I din't think I have used that Feb 27 13:09:54 cool, thanx, latencyTOP sounds also promising from what I can read on that page. If you remember more, just lemme know Feb 27 13:19:09 ok so it appears distro values override my machine def's preferred provider for virtual/kernel Feb 27 13:19:12 it that normal Feb 27 13:20:26 mister_x_: sorry cannot find the tool I patched/used right now. Would need to get my old kernel tree from backup. But I doubt it would be overly useful. Web search brings up much newer results Feb 27 13:21:53 thanks anyway, u1106 :-) Feb 27 15:29:24 How does AUTOREV work when a PREMIRRORS variable is set? Feb 27 15:31:37 jofr: it would want to resolve the latest revision from the upstream, it can't do anything else Feb 27 15:32:49 So it checks the upstream? Even when I have a "git://.*/.*" value in PREMIRRORS? Feb 27 15:36:12 I'm actually hoping that the answer to that is "yes". :p Feb 27 15:38:16 i.e. that it goes to the upstream for "unknown" revisions, and if it is known/set in the recipe, and the mirror has it, it goes to the mirror instead. Feb 27 15:39:55 jofr: the answer is yes Feb 27 15:41:05 RP: Woohoo! Thanks :-) Feb 27 15:59:29 Next question: SSTATE_MIRRORS: If I have more than one set, are they checked in the order they are listed or randomly? i.e. does bitbake attempt to do some load (random) load-balancing? Feb 27 16:03:44 jofr: probably in order Feb 27 16:06:30 RP: Ok :) Thx Feb 27 16:32:39 kanavin: thanks for the qemu system patch. Could we reorder your patches so that one doesn't depend on the gl pieces? Feb 27 16:32:58 kanavin: If we do that I can do a build performance comparison with master Feb 27 16:33:59 kanavin: also, I was thinking we should split the enable virtglrenderer patch into two. The _remove pieces can merge, the changes to the default probably need to wait Feb 27 16:34:27 kanavin: thinking I should take the drop host SDL piece, rburton, any objections? Feb 27 16:34:52 RP: the gl pieces do quite a bit of tweaking to the PACKAGECONFIG lines, and then those are moved around in the recipe split Feb 27 16:35:18 kanavin: I know :( Feb 27 16:36:28 kanavin: I'm not sure we're ready to change the defauults on vritgl/gtk though Feb 27 16:36:54 RP: but the default in runqemu remains sdl Feb 27 16:37:09 you need to opt-in to the gl, via 'gl' or 'egl-headless' Feb 27 16:37:48 sorry :) confusion Feb 27 16:38:01 the default becomes gtk, but without gl Feb 27 16:38:34 kanavin: I am not sure this has had the user exposure we need... Feb 27 16:40:01 RP: the gtk bit? I'm fairly confident in that, it's the gl parts that are more prone to failure. Feb 27 16:43:19 does bit back have problems with shared directories in vagrant Feb 27 16:43:50 anyway, let me rebase the split patches, let's tackle one thing at a time Feb 27 16:44:22 kanavin: I was testing gtk display a bit yesterday and surprisingly the emulated cpu somehow influences it as well, default runqemu gave me iirc -cpu pentium2 and virgl didn't start at all, with -cpu host it started and worked a bit (without cursor, but that might not be gtk display fault) Feb 27 16:45:13 maybe it's similar issue as e.g. qt examples fail to start, because sse2 is missing in emulated cpu Feb 27 16:47:01 as in http://lists.openembedded.org/pipermail/openembedded-core/2018-April/150177.html Feb 27 16:49:52 JaMa: the bsp should be setting the right qemu machine for the tune Feb 27 16:50:29 rburton: so it's oe-core fault? :) Feb 27 16:50:39 JaMa: ie the corei7 tune does -mnehalem for TUNE_CARGS, and -cpu Nehalem for qemu Feb 27 16:50:54 this was default qemux85 Feb 27 16:50:56 6 Feb 27 16:51:17 the sse2 example wasn't qemux86 i guess :) Feb 27 16:52:17 maybe it was ssse3 like in the e-mail, cannot check now Feb 27 16:53:32 kanavin: gtk is a lot heavier than sdl and not really needed if we don't use gl Feb 27 16:55:27 RP: so how do we proceed? Feb 27 16:55:48 http://codepad.org/S1M56iaw Feb 27 16:56:22 is there something special that has to be done to get yocto to run inside a vagrant server Feb 27 17:14:25 kanavin: Why was GTK necessary? Feb 27 17:14:47 JPEW, because I tried everything to make sdl work with GL passthrough, and it just wouldn't Feb 27 17:15:24 hmm, odd. It works on my fedora 29 system (using system qemu, not OE) Feb 27 17:15:37 kanavin: my preference is to reorder the patches so I can test/merge the qemu split Feb 27 17:15:52 RP: so should I rebase the split on top of master? Feb 27 17:16:18 JPEW, I tried fedora's qemu, it would start, but display a blank window where sato is supposed to be Feb 27 17:16:23 kanavin: please. If you split the _remove piece out I'll just merge that separately Feb 27 17:16:47 kanavin: I'm torn on the SDL host thing as it is a neat example of how you can do that Feb 27 17:17:27 kanavin: Hmm.... did you happen to try kmscube? Feb 27 17:18:03 JPEW, nope. Feb 27 17:22:41 kanavin: did you enable opengl support in libsdl2 as in http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/qemu&id=b529b6ba9087d66ed410b60745bd4ca6404b74d1 ? Feb 27 17:23:03 JaMa, I did, of course Feb 27 17:23:28 JaMa, if you want to try to make SDL work on top of my patchset, you are super-welcome Feb 27 17:24:41 RP: sure, I'll get to it tomorrow. time to get a bit of rest :) Feb 27 17:24:45 I don't know why it doesn't work for you Feb 27 17:25:25 JaMa, I don't know either, but do take my branch, and try it if you have a bit of time Feb 27 17:26:02 sorry I don't have time for it now, otherwise I would finish that ticket long ago Feb 27 17:26:15 kanavin: np, thanks! Feb 27 17:33:27 RP: gcc 8.3 is out as we know its mostly bugfix release, I Would think it is safe for master, but I want to get opinion if that would be ok at this stage Feb 27 17:43:19 khem: We can test it, I think it would be good to get in Feb 27 17:47:49 RP: nevermind, I did the qemu split rebase :) Feb 27 17:48:57 kanavin: ah, thanks. I'll figure out some branches and run some tests then Feb 27 17:49:40 RP: cheers. let's handle the rest tomorrow. hope it doesn't explode badly on the AB :) (I did smoke testing though) Feb 27 17:50:11 kanavin: we'll see, thanks :) Feb 27 17:50:44 kanavin: this helps as I know a few interesting patches are probably going to appear in the next 48hours Feb 27 17:51:25 obviously the remaning virgl patches no longer apply, so I guess you'll need to drop them Feb 27 17:51:42 kanavin: right, that was kind of inevitable Feb 27 17:58:28 RP: patch on its way, you asked for trouble Feb 27 18:00:25 khem: I'm my own worst enemy for this... Feb 27 18:00:26 RP: ah sent old one Feb 27 18:00:29 wait Feb 27 18:00:35 * RP waits Feb 27 18:00:55 khem: thanks for the distro features tweak, I'd wondered whether we could remove that default Feb 27 18:07:51 RP:v2 on list now, give it a shot Feb 27 18:08:06 my build has been small core-image-minimal Feb 27 18:08:33 tonight it will be much more Feb 27 18:09:11 khem: Just fired a qemu build to test that split. Will test gcc next Feb 27 18:10:01 RP: I will make v2 for Og patch as well Feb 27 18:10:26 I was thinking of fixing glibc with -Og along the way Feb 27 18:11:30 khem: ok. gcc is queued after the qemu build Feb 27 18:13:32 RP:http://lists.openembedded.org/pipermail/openembedded-core/2019-February/279490.html needs to get in as well Feb 27 18:13:53 it will unbreak rpi and may be others Feb 27 18:16:26 khem: ok Feb 27 18:17:39 khem: somehow that was marked as dealt with here, its queued locally Feb 27 18:21:38 anyone using OE on ecryptfs partition? looks like ecryptfs restricts filename lenght to around 140 chars which isn't long enough for sanity check Feb 27 18:28:01 JaMa:that sounds about right Feb 27 18:30:08 Does that have anything to do with tweet length :) Feb 27 18:33:45 khem: yes, ecryptfs uses twitter for storage :) Feb 27 18:38:58 thats what I thought too :) Feb 27 18:51:46 hmmm Feb 27 19:04:18 is there a guide to using opkg or ipgk Feb 27 21:23:55 RP: hey, thanks for the multiconfig fixes, sorry I didnt have time to do them myself Feb 27 21:28:28 New news from stackoverflow: How to add libwayland-client.so.0 to Yocto/bitbake Feb 27 21:44:44 aehs29_: np, just hope I got them right! :) Feb 27 21:53:22 khem: the qemu patch is looking more problematic than the gcc one! :) Feb 27 22:12:22 RP: eh thats good news in a way :) Feb 27 22:13:28 khem: yes :) Feb 27 22:30:09 wait until you get my libc-headers and kernel changes :P Feb 27 22:58:27 zeddii: feature freeze was monday, sorry ;-) Feb 27 22:58:48 khem: pushed a couple of tweaks to the qemu patch and retesting the lot including gcc Feb 28 00:32:01 RP:cool Feb 28 00:32:49 RP: there is another dlopen() bug in musl that I will send a patch for after my builds finish Feb 28 00:33:22 this was a long standing problem does not happen all the time but now it does show up with qemu-arm while running some gir stuff Feb 28 00:33:42 luckily I was able to get it reproducible in qemu usermode Feb 28 02:14:11 does a recipe automatically build a package **** ENDING LOGGING AT Thu Feb 28 02:59:57 2019