**** BEGIN LOGGING AT Mon Jun 22 02:59:57 2020 Jun 22 06:48:18 good morning Jun 22 06:48:42 howdy mckoan Jun 22 13:04:10 oh, "Running setscene task 3057 of 219", really ? :) Jun 22 13:05:49 the cooker output shows "Running task 367 of 1011" and the next one is "Running setscene task 1400 of 219" (on dunfell) Jun 22 13:06:10 yann: its a known issue, not sure if there is a bug open for it Jun 22 13:06:19 oh ok Jun 22 13:06:24 yann: the task counts are right, the setscene ones can't be really Jun 22 13:06:36 its due to hash equivlance Jun 22 13:08:15 RP: I'm reducing the testcase for the meson bug when configuring mesa - it's likely to be small :) Jun 22 16:55:48 seebs: happen to be around? I have a new pseudo issue which I've mostly debugged for your entertainment ;-) Jun 22 16:55:59 oh no Jun 22 16:56:05 i'm sort of around, which is to say, i'm on hold Jun 22 16:56:27 i keep thinking any day now i'll have free time and catch up on my backlog, then Things Happen Jun 22 16:56:58 seebs: We're seeing machines where the xattr functions are failing with ENOSYS Jun 22 16:57:16 like, the pseudo ones, or the underlying system ones? Jun 22 16:57:17 seebs: that can only happen if real_fsetxattr is null. Jun 22 16:57:27 I've seen that when people try to use xattr on (via pseudo) on filesystems w/o xattr support Jun 22 16:57:30 seebs: its the enosys message from pseudo Jun 22 16:57:53 ahh sounds different from when I saw it.. had to tell the people to use a real FS Jun 22 16:57:57 seebs: the issue is that dlsym() isn't finding fsetxattr and friends in some cases Jun 22 16:58:26 seebs: interestingly dlerror() isn't set Jun 22 16:59:05 seebs: I then discovered that dlsym *is* finding a null symbol in libacl which is the one for fsetxattr in libattr Jun 22 16:59:17 oh weird. Jun 22 16:59:33 seebs: behaving as defined in the man page :/ Jun 22 16:59:58 seebs: I can "fix" this by adding "GLIBC_2.3" versions to our xattr function entries Jun 22 17:00:25 seebs: it does raise a new question though - so we need to wrap the functions in libattr :/ Jun 22 17:00:30 s/so/do/ Jun 22 17:01:22 i don't know what libattr does. if it's calling libc functions, then we probably want to just skip past it to the glibc versions, because its functions just call ours, i guess? but i don't really know. hmm. Jun 22 17:01:56 seebs: I think this only happens if we haven't bound the symbols in libacl. If we have, we find those, things "work" Jun 22 17:02:26 so, why does libattr have null values for these symbols, and why is it linked? Jun 22 17:02:31 seebs: I haven't looked at libattr yet. I was wondering if you happened to know. That is my next step I guess Jun 22 17:03:01 haven't really been attached to this stuff for a while. these days i'm mostly doing performance stuff in Go, which is definitely a very different world. Jun 22 17:03:05 seebs: libacl links to libattr. I think the null entries are the unresolved function pointers in libacl to libattr Jun 22 17:03:44 seebs: I'm way out my normal comfort zone as well... Jun 22 17:04:48 seebs: Some good news from libattr: Jun 22 17:04:50 * These dumb wrappers are for backwards compatibility only. Jun 22 17:04:50 * Actual syscall wrappers are long gone to libc. Jun 22 17:05:25 i wonder if we can just not-link-with libattr. Jun 22 17:05:35 seebs: which I think makes http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=0d5960dcace84a81ea896efa20866218384910e0 a reasonable fix? Jun 22 17:06:14 my concern would be that if the symbols change versions in glibc, we might lose later, but i guess they should stay compatible for a while? Jun 22 17:06:28 i seem to recall having had some prior issues with libattr being Annoying in some way. Jun 22 17:06:36 seebs: they seem to have been around forever and not changed... Jun 22 17:06:52 yeah, fair enough. i think the GLIBC_2.3 versions should stay visible for quite a while. Jun 22 17:07:20 my guess is that at some point pseudo will need to be replaced by something not relying on LD_PRELOAD, and that something like jail/container behavior would be better, but it may take some doing to get there. Jun 22 17:07:44 seebs: I'll tidy this all up, I guess I'm just wondering if there is anything obvious I've missed and if this is the right way to fix the issue Jun 22 17:08:02 seebs: ultimately there may be other ways but not easily without root privs :/ Jun 22 17:08:40 Yeah, I think all the debugger-like stuff tends to require at least the option of getting privileges. Jun 22 17:08:50 And definitely potentially hurts performance. Jun 22 17:09:33 seebs: we've seen this one occasionally for a while, I just had a reproducible test case today to poke at which helps a lot Jun 22 17:10:47 i am not entirely opposed to Go's "we just make syscalls directly" philosophical stance, but it does mean it'll be basically impossible to make any go programs work under pseudo. Jun 22 17:11:24 seebs: right, I can understand it but its problematic for us Jun 22 17:12:39 yeah. i don't really see a fix that isn't basically "become a debugger or require a way to at least transiently have root-like privs". Jun 22 17:15:54 I'm still holding out hope that advocates for non-privileged containers might get there eventually Jun 22 17:20:31 otavio: to your question whether it's sane to extract some common usable to an -fslc branch - I talked to a colleague this afternoon and we realized, that there is no reasonable QorIQ / fsl-lsch3 community Jun 22 17:21:19 otavio: we're more or less on our own and stumble forward at our best ;) Jun 22 17:22:02 otavio: but bringing everything as much as upriver as we can is one of our personal goals Jun 22 17:57:10 Shouldn't /tmp be getting created by initrdscripts ? Jun 22 17:57:41 sno: awesome. When you think it is time, let me know Jun 22 17:58:17 I've got an initramfs-framework script (inherited from refkit) that does headers=$(mnktemp) but this fails because /tmp does not exist Jun 22 17:58:37 ^$(mktemp) Jun 22 17:58:58 moto-timo: the framework base, I think, does it Jun 22 18:00:54 otavio: I don't see it in http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/initrdscripts/initramfs-framework/init#n81 Jun 22 18:07:58 otavio: found it http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/initrdscripts/files/init-install-efi.sh#n141 Jun 22 19:04:10 is there any metric available on sstate/downloads reuse? Jun 22 19:04:47 other than the rather coarse "x tasks not needed" Jun 22 19:12:48 aaaand here we have it https://www.apple.com/newsroom/2020/06/apple-announces-mac-transition-to-apple-silicon/ Jun 22 19:14:13 not great news for linux, that Jun 22 19:14:46 * Letothe2nd shrugs Jun 22 19:16:40 not sure, I'm guessing it may actually be good news for Linux because it'll get significant testing on aarch64? Jun 22 19:17:00 and be it just for docker containers Jun 22 19:31:21 neverpanic: I can imagine Apple will only allow linux in a VM, and lock down the hardware completely otherwise, so no baremetal linux Jun 22 19:32:23 neverpanic: this is move away from being able to run linux anywhere where you want it to, not towards it Jun 22 19:33:46 and aarch64 testing is already more or less covered with raspberry pi Jun 22 19:34:00 Lots of people run 32bit userland on Raspis Jun 22 19:34:22 yeah, but 64bit is now fully useable, no? Jun 22 19:34:38 Good point, however, secure boot on ARM may not be as flexible with machine owner keys as x86_64 Jun 22 19:34:43 Yes. Jun 22 19:39:31 kanavin_home, rburton, sakoman: master now has a fix for the infradead server outage, useful to stop test builds failing Jun 22 19:40:13 Thanks! Jun 22 19:40:56 sakoman: I can pull that straight onto the 1.46 branch if you want, its at least straight forward to test... Jun 22 19:41:17 Yes, please do! Jun 22 19:53:56 Has anyone noticed that toaster reports the machine as the machine configured in local.conf even when using multiconfig with a different machine? Jun 22 20:08:24 RP: thanks! Jun 22 20:16:29 RP: thanks, we can wait and see if mtd-utils recipe needs some kind of SRC_URI fix Jun 22 20:18:54 kanavin_home: the mirror repo is really just there for the fetcher issues. As you say, with mtd-utils we'll have to wait and see Jun 22 20:19:08 the fetcher test issues Jun 22 20:27:12 Is virgl broken on dunfell? I keep getting "failed to open radeonsi" Jun 22 20:29:35 JPEW: it is tested on the AB Jun 22 20:47:20 Hmm Jun 22 20:47:52 It's definitely failing on my Ubuntu 18.04 desktop Jun 22 20:50:01 Can't find drmSyncobjQuery2 Jun 22 20:50:31 JPEW: full error messages please :) Jun 22 20:53:20 kanavin_home: https://pastebin.com/YLFmjUmv Jun 22 20:54:20 With LD_DEBUG=symbols, it give a little more useful: 20516: /usr/lib/x86_64-linux-gnu/libdrm_amdgpu.so.1: error: symbol lookup error: undefined symbol: drmSyncobjQuery2 (fatal) Jun 22 21:00:29 kanavin_home: Ah, I might have it. thats in a newer libdrm, but I think I forgot to rebuild qemu-helper-native after the upgrade Jun 22 21:01:31 JPEW, yes, I was getting to the point where I would say that libdrm in yocto is older than the one on the host, and lacks the needed symbol Jun 22 21:01:56 you need 101 or 102 Jun 22 21:01:57 kanavin_home: I think with the tweak I just found we can upgrade qemu Jun 22 21:02:04 kanavin_home: Right, I did that and assumed qemu would rebuild, but apparently it did not :) Jun 22 21:02:36 RP: nice, and Armin sent bind updates as well Jun 22 21:03:08 kanavin_home: How many upgrades is AUH saying are pending now? :) Jun 22 21:04:27 RP: I have a stash of updates here http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates Jun 22 21:04:48 (still clinging to a belief that 'maintainers' would act on at least some of them in the next few days) Jun 22 21:05:21 with those included, and bind/qemu excluded, it's vulkan... and not much else :) Jun 22 21:05:26 oh, and mesa Jun 22 21:06:18 JPEW: we probably should upgrade libdrm in dunfell then? Jun 22 21:06:40 JPEW: I am rather curious, are you experimenting with virgl, or putting it into use? Jun 22 21:06:48 kanavin_home: nice, mostly small version deltas too Jun 22 21:07:18 kanavin_home: We use it to do development off-hardware with i386 Jun 22 21:07:18 RP: yeah I run them through the AB today, only elfutils needs further fixing Jun 22 21:07:56 kanavin_home: We also boot it with u-boot, which is also broken for some reason :) Jun 22 21:09:07 sakoman, kanavin_home: Yes, I think we need to upgrade libdrm in dunfell Jun 22 21:17:46 kanavin_home: A, u-boot isn't broken, it was just the graphics. I can confirm that upgrading to 2.4.102 fixes it Jun 22 21:19:16 JPEW: I am more surpised that ubuntu 18.04 has something this recent, but maybe it's part of their hardware enablement stack that they keep current Jun 22 21:19:41 kanavin_home: Ya, looks like it's because of the AMD drivers Jun 22 21:21:07 blerg. Anyone tried to compile the latest luaposix? It looks like they completely gave up on cross compiling support :( Jun 22 21:22:00 JPEW: lucky you have AMD card. Here they decided everyone should have nvidia, and nouveau is very slow :( Jun 22 21:22:40 I am torn between adding support for the blob to yocto's virgl setup, or just declaring the linus thing Jun 22 21:23:07 https://www.google.com/search?client=firefox-b-d&q=linus+torvalds+nvidia Jun 22 21:24:37 kanavin_home: nouveau is okay if you only do web browsing other than that :) Jun 22 21:25:15 mranostay: it becomes less okay on UHD resolutions :( Jun 22 21:25:25 noticeably laggy even with regular desktop things Jun 22 21:34:04 yeah last time i used it like 4-5 years ago it was pretty unusable Jun 22 21:38:53 tgamblin__: FWIW I sent a patch to try and improve logging for the 1 != 2 error for rndCmd stdin Jun 22 21:44:22 tgamblin__: Actually, I can make it fail Jun 22 21:55:37 tgamblin__: I'll send a patch. Now you get to fix one of my bugs in return, right? :) Jun 22 22:02:48 RP: take your pick :) Jun 22 22:27:28 armpit: I think we may need dhcpcd in OE-Core to replace dhcp-client? :/ Jun 22 22:57:28 RP, atleast dhcpcd is maintained Jun 22 22:58:44 * armpit needs to look into more things **** ENDING LOGGING AT Tue Jun 23 03:03:14 2020