**** BEGIN LOGGING AT Sun Dec 16 02:59:59 2018 Dec 16 03:20:27 New news from stackoverflow: DEBUG_FLAGS in Yocto is always used Dec 16 03:23:38 the attr thing seems harmless, i think? so far as i know, what we're doing for attr is right, at the moment -- that's still what the getxattr(2) page says to do. Dec 16 03:24:26 i think the libxattr change from using syscall to using glibc's wrappers may have been a bad idea (because their code interacts weirdly with things like fakeroot). Dec 16 03:24:46 but i don't think the header change is necessary or anything; the existing header works and makes sense, and generally following the man pages for a syscall should be safe. Dec 16 09:57:13 [Sno]: I don't think that one is from your patch Dec 16 09:58:18 seebs: With the new version of attr, pseudo fails to build :/ Dec 16 10:01:05 seebs: I'm not going to rush into upgrading attr due to this, particularly if upstream reverted Dec 16 10:03:01 RP: [Sno] there are several build failures in meta-openembedded due to the perl upgrade Dec 16 10:03:08 I have sent the pointers Dec 16 10:04:08 khem: I think the glibc issue may be the localedef patch changes :/ Dec 16 10:04:37 khem: Some bits of localedef-add-to-archive-uses-a-hard-coded-locale-pa.patch look to have gone missing? :/ Dec 16 10:05:44 khem: I suspect you have to clean and install cross-localedef from sstate to reproduce Dec 16 10:27:21 [Sno]: In the perl-rdepends file, why does ${PN} become perl ? Doesn't that break multilib? Dec 16 12:33:41 Hello everybody. I set ARM_INSTRUCTION_SET = "arm" in local.conf and even in particual recipe, but accroding to the result - it does not work (after setting that, all instructions should be in 32bit size, but the don't) Dec 16 12:35:09 the output of "bitbake -e | grep ARM_INSTRUCTION_SET " is ARM_INSTRUCTION_SET="thumb", so I guess something overrides my setting Dec 16 12:37:37 nacknick: right above this line, it'll tell you where the value comes from. Dec 16 12:42:23 neverpanic, well... it does not Dec 16 12:43:02 Well, can you pastebin the lines above that from bitbake -e? Dec 16 12:43:37 you mean without the grep? Dec 16 12:43:50 let me check it out Dec 16 12:44:10 Yes, I mean without the grep. Dec 16 12:58:04 <[Sno]> RP: I have to leave in an hour and something to prepare Dec 16 13:00:17 <[Sno]> RP: I didn't change the header of perl-rdpends_%.inc - so when multilib is broken by that, it supposed to derived from past ;) Dec 16 13:00:43 <[Sno]> When I have a test-case, I'd like to fix it anyway - but maybe after commit Dec 16 14:58:20 so it looks like the new version of attr may be just plain broken Dec 16 14:58:47 Enrico got back to me, and on Fedora 28, doesn't define ENOATTR. I don't know whether they changed their man pages too, but this seems like a severe API-breaking change. Dec 16 15:00:18 seebs: it does sound like something isn't right :/ Dec 16 15:36:41 Enrico apparently filed a bug with the kernel for the man page documenting a thing that got taken out. I am offended. Dec 16 15:37:05 If the man page says something returns ENOATTR, then you are stuck providing that name for that thing, because if you just yank it out, you're breaking valid code. Dec 16 15:37:55 Changing the error something returns abruptly without a period of years of warning that it's deprecated would be, like, 90s-era Microsoft. Dec 16 15:53:17 seebs: is this the offending patch? https://src.fedoraproject.org/rpms/attr/blob/master/f/0002-attr-2.4.48-switch-back-to-syscall.patch Dec 16 15:53:24 RP: ^^^ Dec 16 15:55:16 oh wait, that's master branch Dec 16 15:55:41 the F28 branch seems to package just the tarball Dec 16 16:01:14 seebs: new version of attr does provide ENOATTR, they just moved it to a different header Dec 16 16:01:27 just looking at tarballs here https://download-mirror.savannah.gnu.org/releases/attr/ Dec 16 16:05:13 Hello again. Last week I added a command in "do_install_append" to replace a package's binary inside "image" folder, after I loaded the board, I saw that it actually replaced the binary. Today I tried to do it again, it's replacing the binary inside 'image' folder, but when loading the board, it seems that the original binary was saved/packaged. Why is that? Dec 16 16:14:22 If someone has any idea - I'll glad to hear Dec 16 16:18:20 Is there a command to force rebuild? because yocto does not detect my changes Dec 16 16:22:19 never mind. back to my first question please... Dec 16 16:31:56 hdah'n Dec 16 16:32:22 ... that is what happens when my keyboard is off by one. my hands were in the right place, the keyboard wasn't Dec 16 16:32:36 so that's the patch that restores syscall usage in attr, but that's not directly affecting things. Dec 16 16:33:07 it looks like the ENOATTR change was elsewhere and may have been unintentional, but looking at it, it appears that if I include the recommended headers, ENOATTR is gone. Dec 16 16:33:38 i don't have any clue what they're doing. It looks to me like the attr package and glibc's xattr implementation are out of sync in some way, and glibc's implementation may be inconsistent with the kernel docs. Dec 16 20:22:07 RP: what's the story with building YP on arm64? is that announced or documented somewhere? Dec 16 20:52:01 RP: it seems generate_locale_archive() even though env is passed launches cross-localedef without providing the env to it Dec 16 20:53:06 on cmdline cross-localedef is seeing exact problem when LOCALEARCHIVE is set Dec 16 20:53:14 to nothing Dec 16 20:53:26 and when I set LOCALEARCHIVE=/tmp/foo then it works ok Dec 16 20:54:14 I print the env inside generate_locale_archive then I can see that LOCALEARCHIVE is set Dec 16 20:54:55 question is then why is subprocess.check_output(cmd, env=env, stderr=subprocess.STDOUT) not passing it to cmd when exec'ing it Dec 16 20:55:42 see https://gist.github.com/73238c2f7f95f5c8384505c79ecdedbc Dec 16 20:57:16 see 'LOCALEARCHIVE': '/mnt/a/yoe/build/tmp/work/raspberrypi3_64-yoe-linux/core-image-lsb-dev/1.0-r0/rootfs/usr/lib/locale/locale-archive' Dec 16 21:43:48 Hello, I want to install my own CA certificate chain in my image. I have made this work by editing the `ca-certificates` recipe. Basically just adding my file and updating the do_install function to install it. I think I should use a .bbappend file in one of my own layers to implement this. Do I have to copy the entire do_install function into my .bbappend file, or is there a better way to do that? Dec 16 21:50:25 dresserd: no need, just put your extra commands in a do_install_append() in your bbappend Dec 16 21:50:52 then that part will be effectively concatenated to the do_install before it's executed Dec 16 21:52:15 bluelightning: Thanks. Dec 16 22:18:19 kanavin_home: its being worked on, not announced yet Dec 16 22:18:30 kanavin_home: it works fine to a point Dec 16 22:20:08 khem: that seems strange :/ Dec 16 22:33:00 RP: I think you were right I accidentally dropped the hunk to apply to enlarge_archive() Dec 16 22:33:09 I am trying with that now lets see Dec 16 22:33:26 stack trace was not conclusive but I think that was the problem Dec 16 22:37:17 khem: That was what it looked like when I looked at the patches... Dec 16 22:38:26 lets see build is under progress Dec 16 22:39:48 RP: perl upgrade is causing some regressions, I am hoping someone will help in fixing those in meta-openembedded, hopefully we can wait for few days Dec 16 22:40:59 khem: right, I don't know if Jens can help or not but I'll hold off applying it Dec 16 22:41:59 RP: eventually it might fall all on me, I dont know the magic pill for creating interest in people :) Dec 16 22:42:33 khem: I know the problem, if you do find it, let me know? :) Dec 16 22:42:37 RP: btw. I am planning on sending some of glibc patches to upstream including http://git.openembedded.org/openembedded-core/tree/meta/recipes-core/glibc/glibc/0034-inject-file-assembly-directives.patch Dec 16 22:43:05 khem: great, I wasn't sure that one was right or not and needed more time to look into it Dec 16 22:43:17 khem: if you need anything from me, let me know Dec 16 22:43:26 khem: gcc patches are on my todo list too Dec 16 22:43:31 last para in comment is not encouraging in that patch, I think its a good patch Dec 16 22:43:43 for gcc we still have some time Dec 16 22:44:05 khem: You don't need to include the last para :) Dec 16 22:44:19 khem: if they don't like it, they might at least know how to fix it properly Dec 16 22:44:19 OK. and you dont have sign-off on that patch Dec 16 22:44:28 so I will inject it Dec 16 22:45:17 khem: that is fine. I consider "RP" in there a sign off. I still am not sure these S-o-b lines in patches entirely makes ense Dec 16 22:46:05 sort of ok, but SOB usually includes a NAME format Dec 16 22:49:15 khem: I know. Please feel free to add it Dec 16 22:52:24 Hmm, looks like we managed to get md5 collisions in codeparser :( Dec 16 22:52:37 probably need to move to sha256 Dec 16 23:02:15 RP: yikes Dec 16 23:07:40 bluelightning: reading up on md5 I think I can see how this could happen and why we really do need to switch :/ Dec 16 23:08:26 thankfully easy to do, just annoying and will increase the cache size Dec 16 23:39:42 RP: good suggestion, the problem is fixed. I have updated the patch at http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/glibc-2.29 Dec 16 23:40:07 RP: the issue you saw should be fixed now. Give it another shot if you find another window on AB Dec 17 00:10:17 hi **** ENDING LOGGING AT Mon Dec 17 03:00:00 2018