**** BEGIN LOGGING AT Tue Dec 18 03:00:00 2018 Dec 18 09:02:10 Hi. When image is booting, what the logo of psplash (https://github.com/g0hl1n/psplash) is not displayed? Dec 18 09:03:24 My target is to add a customized boot logo, I thought that replacing the images of psplash will work, but the original images are not dispalyed, so I'm not sure that is the correct method Dec 18 09:04:08 The best result for me is to replace "open embedded" logo and keep the progress bar Dec 18 09:04:28 Do someone here know how to do that? Dec 18 09:04:33 does Dec 18 09:05:17 why the logo*** (on the first sentence) Dec 18 10:22:27 RP: yes please (the AUH patch) Dec 18 10:23:12 kanavin: cool :) I was also thinking of having it just mark all images as not upgradable since devtool would just error later about it? Dec 18 10:23:32 currently I keep getting emails from AUH about build-appliance-image Dec 18 10:43:34 RP: I can add that to exception list Dec 18 10:44:07 build-appliance-image is special as it has SRC_URI, other images should be find Dec 18 10:44:08 fine Dec 18 11:11:21 kanavin, RP: i was thinking auh needs a skip variable, easily set in packagegroups and images. Dec 18 11:13:14 rburton: there is a blacklist, I just added build-appliance-image to that Dec 18 11:13:34 rburton: packagegroups and images should be skipped by default, as their version is always 1.0 Dec 18 11:13:55 what if something is genuinely 1.0? Dec 18 11:15:02 rburton: what I mean is that packagegroups always have current *and* latest version set to 1.0, and so they are skipped Dec 18 11:15:14 right Dec 18 11:16:17 I could find a solution for my yesterday question: why diff.diffutils under package folder is not the same one that inside /usr/bin inside the final image. Does someone have any explanation? Dec 18 11:16:27 I could not** Dec 18 11:17:32 is bitbake takes the package's binary from somewhere else? is there any "cache" or something similar? Dec 18 11:17:47 taking ** Dec 18 11:17:54 nacknick: did you check that the contents of the package in the deploy dir matches what you expect? Dec 18 11:18:44 rburton do you mean inside deploy/images/...?? Dec 18 11:18:52 no, that's images not packages Dec 18 11:19:01 i mean deploy/rpm or deploy/ipk or whatever package format you're using Dec 18 11:19:21 oh Dec 18 11:19:24 no I did not Dec 18 11:20:00 you should Dec 18 11:20:29 what should I check exactly please? Dec 18 11:20:45 find the diffutils package, unpack it, check it has what you expect Dec 18 11:20:48 those folders are full with .deb files, not the final binaries Dec 18 11:21:19 man dpkg-deb, specifically -x Dec 18 11:21:29 and if it does not match what I expect? Dec 18 11:21:33 images are built from packages, they're the packages Dec 18 11:21:48 then you've reduced the scope of the problem Dec 18 11:22:07 and what can I do regard this? Dec 18 11:22:24 well lets work on that when you know if the packages match what you expect Dec 18 11:22:26 delete the .deb? Dec 18 11:22:49 ok... I'll let you know in 30 minutes (I'm just in a middle of something) Dec 18 11:23:01 thank you so much! seems a good direction Dec 18 11:27:09 kanavin: I guess that works too :) Dec 18 11:28:41 oh jeez, hit shebang length limits in bitbake recipes using some python scripts. #!/path/to/rss/python is too long. Any ideas how to resolve? Dec 18 11:31:05 mcfrisk: don't use python-native? :) Dec 18 11:31:50 or pip... Dec 18 11:32:28 hi, does anyone use ccache via the CCACHE var in bitbake.conf? I configured it to use ccache, set the directory etc. but all I get are 181 files that state that the compiler couldn't be found after a complete build Dec 18 11:52:20 jkliemann: try inheriting the ccache class? Dec 18 11:54:33 RP: where is this required? i want to build anything with ccache so do i need to inherit it everywhere? as far as i understand i inherit classes in bbfiles when i want to use some library? Dec 18 11:55:38 jkliemann: local.conf, INHERIT += "ccache" Dec 18 11:55:46 or your distro config Dec 18 12:00:03 rburton: do we need http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/scripts/distro/build-recipe-list.py ? Dec 18 12:05:03 <_mac13_> Hi, is there a possibility to build two rootfs with a single image recipe? Dec 18 12:05:17 _mac13_: no Dec 18 12:05:27 _mac13_: not easily anyway Dec 18 12:05:40 _mac13_: just have one image recipe depend upon another? Dec 18 12:09:04 RP: thanks that was what was missing Dec 18 12:10:56 <_mac13_> RP: I've try this as at my first attempt, but if I put my second image as depends only one rootfs shows in deploy, but thanks, will look into this and try to find solution Dec 18 12:13:05 _mac13_: try do_rootfs[depends] += "other-image:do_rootfs" Dec 18 12:15:33 rburon, there are many "diffutils*.deb" files, I checked one of them and it contains the correct binary Dec 18 12:15:36 what next? Dec 18 12:19:48 nacknick: then assuming that package is going into your image, you're not looking at an up to date image Dec 18 12:22:32 kanavin: Where did you tweak that out of interest? Is there some config somewhere? I'm a bit nervous that isn't in a repo somewhere :/ Dec 18 12:23:08 <_mac13_> RP: Thanks a lot Dec 18 12:23:28 RP: i'll ask aaron Dec 18 12:24:34 rburton: I sent a patch out to remove it, I think we need to reimplement it. So speak quickly if its really needed Dec 18 12:24:50 odds are good that its not actually used Dec 18 12:24:56 if it is we'll just reimplement it Dec 18 12:31:34 rburton: right, I think that would be the best way forward... Dec 18 12:42:31 rburton, what do you mean? which image? Dec 18 12:44:40 nacknick: the image you said you're building and looking in Dec 18 12:46:42 hello! Dec 18 12:46:44 how to approach this: I have recipe with package A (and B), by default in image recipes A is installed. but If I say I want B in local.conf, B would be installed and A not (rconflicts requires that A is removed from image recipe, rprovides for B to be A, causes B to be installed even if not asked for) Dec 18 12:47:33 ak77: have them both provide some virtual thing Dec 18 12:47:37 yeah that Dec 18 12:48:02 then its PREFERRED_PROVIDER="asdfasdf" to select the desired one Dec 18 12:49:26 thank you, let me check that Dec 18 12:50:59 well, no, that would select between *recipes* Dec 18 12:51:00 meh, its PREFERRED_PROVIDER_virtual/yourthing="asdfasdf" to select the desired one Dec 18 12:51:13 the description suggests that there is a single recipe writing multiple packages Dec 18 12:51:55 hmmmm ok, then its probably rather some form of distro feature Dec 18 12:51:55 ak77: can you clarify? Dec 18 12:52:03 no much easier way to solve it Dec 18 12:52:08 yes. Dec 18 12:54:33 one recipe producing alternative packages, or many recipes? Dec 18 12:54:38 I have many each providing ${PN}, and ${PN}-dbg... they all inherit from a custom class. Dec 18 12:54:43 many recipes Dec 18 12:54:50 right PREFERRED_PROVIDER then Dec 18 12:55:30 recipe eg foo-fast RPROVIDES foo, foo-slow RPROVIDES foo Dec 18 12:55:33 image RDEPENDS on foo Dec 18 12:55:33 all good. but we found a way to proxy call those "executables" in ${PN} packages. to install "proxy" we have ${PN}-extsrc, but that should exclude original ${PN} Dec 18 12:56:10 foo-slow foo-fast should have identical paths in so they're drop-in changes Dec 18 12:56:24 then PREFERRED_PROVIDER_foo = foo-fast Dec 18 12:57:11 yeah, I get it now. but don't like it. It's development only package, and I don't wanna equip (many) recipes with this mechanism just because of development Dec 18 12:57:54 so just have the extra recipe rprovide the original names and use preferred provider to swap Dec 18 12:58:29 you can install foo in an image but have foo redirected to foo-somethingelse even if there's a foo recipe alrady Dec 18 12:58:38 its just not as obvious Dec 18 12:59:05 why extra recipe? with original recipe and (already present) custom class I can add second providers for all of them Dec 18 12:59:30 you said there were multiple recipes Dec 18 12:59:42 why don't you explain what you're *actually* trying to do Dec 18 13:01:29 the web user interface if built of many parts that are compiled (webpacked,...) by custom class that many recipes inherit Dec 18 13:01:51 Hello! In the standard project yocto/poky , by default the cross-compiler is built without sanitizers? Can you tell me how to fix this, so that packages, that get into the image csn be builded with -fsanitize options? Dec 18 13:02:34 so, each recipe provides a package that provides piece of compiled js code. ... custom index.html handler collects them all and serves them. so far so good. Dec 18 13:03:25 we got a way to change one piece of such js code with something that proxies a call outside of emulator to an instance that runs on host computer - faster and easier development Dec 18 13:04:11 so, now I wanted to add some code to this custom class that all such recipes inherit to provide alternative package with proxy functionality instead of real piece of js code Dec 18 13:04:30 rburton: does that make sense? Dec 18 13:04:49 just have foo-proxy rprovide foo Dec 18 13:05:19 then i think prepending foo-proxy to IMAGE_INSTALL will force that one in Dec 18 13:05:57 rburton: I observe other problem. all I get is these proxy packages Dec 18 13:06:13 RDEPENDS_${PN}-extsrc_remove = "${PN}" RPROVIDES_${PN}-extsrc = "${PN}" RREPLACES_${PN}-extsrc = "${PN}" Dec 18 13:06:45 uh.. RREPLACES might be the problem Dec 18 13:07:03 hi, is it possible to static build qt5 libraries ? Dec 18 13:07:21 ak77: there's no default dependency on PN unless you've added it yourself so the first remove is redundant Dec 18 13:09:28 I need to build a standalone qt application, so that it loads faster, does qt gives the option to build libs as static ? Dec 18 13:10:47 I meant, does yocto gives the option to build qt libs as static Dec 18 13:12:22 RP: there is a custom config in auh.yoctoproject.org:/home/auh/build/updgrade-helper.conf Dec 18 13:12:56 RP: the repo has a config template Dec 18 13:13:00 Hi, im trying to add password restrictions (minimum length, dictionary check, etc.) for a busybox-based device with yocto. libpam and cracklib are installed to the image, but it seems that all busybox applets related to this (adduser, login, etc.) ignore the pam modules.. I enabled CONFIG_PAM in busybox config. any idea what am i missing? Dec 18 13:14:25 i check if PAM modules are used by adding "password required pam_deny.so" to all /etc/pam.d/* files. if i understand correctly - this should cause errors to all running apps that use pam.. Dec 18 13:15:15 ranran: no idea about qt but if you don't pull in the no-static-libs.inc into your distro config then you should be getting static libraries Dec 18 13:15:36 ranran: using that is the default in poky so if you're using that, then 1) that's why and 2) don't use poky, it's an example. make your own. Dec 18 13:17:40 kanavin: thanks Dec 18 13:19:29 RP: the auh repo still doesn't have your commit? Dec 18 13:23:08 rburton: thanks, I do find it in source files no-static-libs.inc , so i will try to remove it, and see if static libs are created ? Dec 18 13:23:45 rburton: it should also create the host libraries as required (we build the qt application in host) ? Dec 18 13:23:46 rburton: thank you. RPOVIDES_${PN}-proxy = "${PN}" works as advertised Dec 18 13:25:55 *RPROVIDES Dec 18 13:26:57 kanavin: it does now :) Dec 18 13:27:23 RP: cheers, we'll find out in a month if it works as advertised :) Dec 18 13:29:10 kanavin: lets hope so... Dec 18 13:29:27 kanavin: definitely think this is the way forward though Dec 18 13:30:37 RP: certainly, I just need to further improve AUH to print something that resembles the old csv Dec 18 13:41:39 (tas) Hello! In the standard project yocto/poky , by default the cross-compiler is built without sanitizers? Can you tell me how to fix this, so that packages, that get into the image csn be builded with -fsanitize options? Dec 18 13:44:55 tas: i'm guessing, depend on gcc-sanitizers Dec 18 13:47:26 rburton: gcc-sanutizers builded like package by cross-compiler for runtime to image Dec 18 13:48:23 But how to add sanitizers to cross-compiler components Dec 18 13:48:57 And build other packages with sanitize-options Dec 18 13:50:08 add the args to CFLAGS Dec 18 13:50:16 tas: Add DEPENDS += "gcc-sanitizers", add CFLAGS += "-fsanitize=something" LDFLAGS += "-fsanitize=something". Dec 18 13:50:25 Worked fine for me last time I tried it. Dec 18 13:51:20 neverpanic: Ok, thank you, I try this! Dec 18 13:53:08 But what about linking to sanitize-libs during cross-compiling? Dec 18 13:53:47 Cross-compiler by default don't have libsanitizers Dec 18 13:55:01 That's why you also need to put it in LDFLAGS and why you're specifying DEPENDS += "gcc-sanitizers"; that provides the libraries. Dec 18 13:58:49 Ok! Dec 18 14:20:07 does someone know where the executable binaries got their name? for instance, vim, called "vim.vim" inside image/ folder. why ".vim"? Dec 18 14:31:55 New news from stackoverflow: External Keypad - General Purpose Input (GPI) Events Dec 18 14:38:22 nacknick: update-alternatives.bbclass Dec 18 15:48:50 Is there a YPTM today? Dec 18 15:51:39 JPEW: not according to my calendar Dec 18 15:51:46 (first tuesday of the month) Dec 18 16:01:49 JPEW: no, I don't think so Dec 18 16:02:00 Ok, thanks Dec 18 16:02:02 JPEW: did you see whether still need the close at fork pieces? Dec 18 16:02:26 JPEW: would love to get the tests in too but they depend on the close at fork bits Dec 18 16:02:58 Correct. I will try without.... I can split the tests up too Dec 18 16:11:33 JPEW: that would be great. I'd rather not have that complexity if we don't need it Dec 18 16:52:16 RP: libmpx is removed from gcc-9 I was wondering if we should disable it on gcc8 as well. Only x86 targets enable it Dec 18 16:52:48 see http://git.openembedded.org/openembedded-core-contrib/commit/?h=yoe/mut&id=2a49d60859e0319683281d98513dad2ddf7b3265 Dec 18 16:53:03 khem: lets just remove it Dec 18 16:53:08 right now, I am doing it gcc9 specific way but I guess intel stopped supporting it long time ago Dec 18 16:53:12 ok Dec 18 16:54:11 address sanitizers are better I guess than mpx Dec 18 16:54:23 khem: I have an interesting experiment. I removed virtual/${TARGET_PREFIX}libc-for-gcc from DEPENDS in gcc-cross.inc Dec 18 16:54:39 khem: things still appear to work Dec 18 16:55:16 khem: need to run more tests but... Dec 18 17:00:32 RP: hmm indeed but since we do have dummy .so as part of libc-initial we might be ok Dec 18 17:01:31 khem: hmm, it did blow up now. I guess need clean sysroots to test this Dec 18 17:02:21 RP: and finally gcc9 has also deleted spe port from its sourcs Dec 18 17:20:16 RP: I sent a fix for x32 issue for libxcrypt, upstream is waiting on runtime tests, do we have h/w testing for x32 in AB or elsewhere Dec 18 19:02:47 New news from stackoverflow: Adding DISTRO_FEATURES to image bitbake recipe Dec 18 19:18:44 khem: I tested and merged it! :) Dec 18 19:19:07 khem: Any h/w testing would be done by Intel QA rburton? Dec 18 19:28:17 what is yocto trying to say me? http://paste.debian.net/plain/1056450 Dec 18 19:28:19 Exception: TypeError: can only concatenate list (not "str") to list Dec 18 19:28:30 reads like a deep internal error in some python fu Dec 18 19:42:17 building the ext_sdk works Dec 18 19:42:18 strange Dec 18 19:51:35 hmm, seems to have something to do with locale settings. wtf.. Dec 18 20:08:36 khem: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=9640c4d25019188b9c69eb9b5b286ba287dd82fc seems to work... Dec 18 20:10:28 fray: the above removes the site_cache piece as I couldn't make that work without -initial :( Dec 18 20:10:31 rburton: ^^^ Dec 18 20:11:25 derRichard: its saying you tried to do str() + list() Dec 18 20:11:40 derRichard: i.e. "foo" + ["bar"] Dec 18 20:12:15 RP: yeah, but what does that mean in terms of yocto? :D Dec 18 20:12:40 derRichard: I'd have to look at the code to figure that out Dec 18 20:13:18 the code is: pkgs = fnmatch.filter(pm.list_installed(), "nativesdk-glibc-binary-localedata-*.utf-8") Dec 18 20:13:48 so, what fnmatch.filter returns is not what the install function expects Dec 18 20:13:51 RP, ya I don't think there are any issues w/ ditching -initial.. just have to figure out about the site-cache.. I know we can still reasonably generate it w/o glibc.. just may have to be done in a couple of steps.. (or we don't generate, but just hard code the values completely) Dec 18 20:14:42 can it be that fnmatch.filter(pm.list_installed(), "nativesdk-glibc-binary-localedata-*.utf-8") returns a single string instead of a list of strings? Dec 18 20:28:44 derRichard: my python gets weak there Dec 18 20:29:40 yes :( Dec 18 20:29:53 i'm currently reviewing my locales settings Dec 18 20:35:52 my snake fu is also weak ;) Dec 18 20:40:13 khem: tbh not sure, will find out re x32 Dec 18 20:52:27 khem: the only difference between a gcc-cross with libc in the depends and one without appears to be a single define in auto-host.h and differences in the limits.h files Dec 18 20:52:41 There has to be a better way to do this Dec 18 20:57:18 I'm curious about hte limits.h file.. Dec 18 20:58:54 fray: basically whether to recuse into a system provided file (we want the answer yes) Dec 18 20:59:01 no libc means no Dec 18 21:01:48 in some of these cases, we may be able to take the header from libc in order to generate libc.. (more or less what was being done before)... or even define them on an architectural basis (site-config like).. the catch with doing so is to verify the values are sane and don't break Dec 18 21:04:05 fray: "touch limits.h" may be enough Dec 18 21:04:15 yes it might.. Dec 18 21:04:36 huh, interesting Dec 18 21:04:46 I've seen probles in the past where limits.h can get wrong values that filter through the build though... but that was a long time ago Dec 18 21:04:57 gcc only checks if it exists so a dummy one might work Dec 18 21:05:30 RP: found the problem, SDKIMAGE_LINGUAS was set to "non" Dec 18 21:05:32 the key is we rebuild libgcc after glibc. With the separate build of libgcc we have, that is already covered Dec 18 21:05:35 * = "none" Dec 18 21:06:15 so the flow would be gcc-cross -> libgcc-initial -> glibc -> libgcc Dec 18 21:12:52 derRichard: would be nice to have better error checking for that Dec 18 21:13:50 RP: YES :-) Dec 18 21:14:09 RP: maybe time for my first patch Dec 18 21:18:37 derRichard: sounds good to me! Dec 18 21:37:09 RP: on the other hand, is setting SDKIMAGE_LINGUAS to "none" an error? i thought this is legit Dec 18 21:37:18 IMAGE_LINGUAS="none" works too Dec 18 21:38:29 derRichard: good question. Its odd to have different behaviours Dec 18 21:39:13 i'll write to the mailinglist :) Dec 18 21:39:56 derRichard: let me have a look Dec 18 21:40:40 ok Dec 18 21:41:57 derRichard: what makes you say "none" is supported in IMAGE_LINGUAS ? Dec 18 21:42:55 derRichard: basically, "none" makes it add *locale-none to the image Dec 18 21:45:25 RP: in meta/classes/populate_sdk_base.bbclass i read Dec 18 21:45:26 # List of locales to install, or "all" for all of them, or unset for none. Dec 18 21:45:27 SDKIMAGE_LINGUAS ?= "all" Dec 18 21:45:33 derRichard: basically one is a soft glob where matching nothing doesn't matter, the other one gets upset if there are zero matches Dec 18 21:45:52 i assumed that "none" is also okay Dec 18 21:45:58 it doesn't say to set it to none, it says it'll install none if it's unset Dec 18 21:46:40 hmm, you are perfectly right kergoth. i read "none" in the wrong way Dec 18 21:47:39 derRichard: I suspect if you put "foobar" into IMAGE_LIGUAS it will silently ignore it whilst SDKIMAGE_LINGUAS will error Dec 18 21:48:05 RP: yes. Dec 18 21:48:25 derRichard: Catching the error in the SDKIMAGE_LINGUAS case would still be prefereable Dec 18 21:49:57 ...reading meta/lib/oe/sdk.py to find a sane way to warn stupid users like me :) Dec 18 21:54:15 derRichard: an "if not pkgs" in that function may be a start? Dec 18 21:54:26 derRichard: I'm getting flashbacks of a bug now :/ Dec 18 21:56:50 meta/lib/oe/package_manager.py has already some aid, but it does not help in this case Dec 18 21:56:53 if len(pkgs) == 0: Dec 18 21:56:55 return Dec 18 21:57:57 for lang in linguas.split(): Dec 18 21:57:58 pm.install("nativesdk-glibc-binary-localedata-%s.utf-8" % lang) Dec 18 21:58:01 this fails Dec 18 21:58:08 in my case it aws nativesdk-glibc-binary-localedata-none.utf-8 Dec 18 21:58:28 but this makes no sense Dec 18 21:58:33 * derRichard needs to think again Dec 18 21:59:17 derRichard: something isn't adding up here Dec 18 21:59:29 i have an idea, give me a few minutes Dec 18 22:08:27 RP: "none" is not the problem, SDKIMAGE_LINGUAS is broken for any values except "all". pm.install(pkg) expects pkgs being a list, the code in this function does [] + pkgs Dec 18 22:08:38 if pkgs is a string, it will explode like in my case Dec 18 22:08:48 install_locales() does: Dec 18 22:08:59 # Install the binary locales Dec 18 22:08:59 if linguas == "all": Dec 18 22:08:59 pm.install_glob("nativesdk-glibc-binary-localedata-*.utf-8", sdk=True) Dec 18 22:09:02 else: Dec 18 22:09:05 for lang in linguas.split(): Dec 18 22:09:07 pm.install("nativesdk-glibc-binary-localedata-%s.utf-8" % lang) Dec 18 22:09:23 the "all" case is good. the "for lang in linguas.split()" case is broken for any inputs Dec 18 22:09:58 pm.install(["nativesdk-glibc-binary-localedata-%s.utf-8" % lang]) Dec 18 22:10:04 should to the trick Dec 18 22:10:38 *do Dec 18 22:19:40 67615e01751b ("rootfs_rpm.bbclass: migrate image creation to dnf") Dec 18 22:19:48 seems to be the first bad commit Dec 18 22:29:36 derRichard: yes, well spotted! Dec 18 22:51:09 RP: shall i file a bug or how to proceed? Dec 18 22:52:08 derRichard: send a patch? Dec 18 22:53:41 RP: ok Dec 18 22:53:51 patch. Huh. What is this primitive form of communication you speak of? Dec 18 22:53:55 * paulg runs Dec 18 22:54:24 paulg: lol, you here :D Dec 18 22:57:46 paulg: sent by courier on punch cards, obviously Dec 18 22:58:09 Unacceptable! Dec 18 22:58:30 We all know it needs to be mag tapes in a station wagon! Dec 18 22:59:19 paulg: never underestimate the bandwidth :) Dec 18 23:00:26 * paulg imagines all the millenials scratching their heads and googling what a station wagon is, let alone a mag tape. Dec 18 23:00:56 paulg: punch cards is a drinking card game ;-) Dec 18 23:01:27 <_csg> People think the wood panels were aesthetic, but its really just to avoid degaussing the car after the trip Dec 18 23:03:37 station wagon is also called combi in some geographies Dec 18 23:04:01 RP: Are we working on switching qemuarm to armv7 cpu Dec 18 23:04:41 so it seems fedora is skipping next release so no f31 for a while Dec 18 23:06:19 a year is a good cadence IMO. 6months is a lot more churn its just CI excercise in my opinion Dec 18 23:07:43 maybe they will come to this revelation Dec 18 23:09:14 khem: yes, jonmason is Dec 18 23:13:47 khem: I'd be really interested on your take on these gcc bootstrap changes... Dec 18 23:14:37 hmm, making it to assertion failures is bad :} Dec 18 23:15:26 RP: are you trying to remove need for gcc-initial ? Dec 18 23:17:06 khem: yes, wondered if it was possible Dec 18 23:18:37 khem: trouble is the thread model is fixed inside gcc, libgcc-initial is single, libgcc is posix. We need libgcc-initial to build glibc. You need a "single" compiler to build libgcc-initial and a posix threaded one to build libgcc Dec 18 23:18:38 if there was no automake it was certainly, possible, we need to tame automake and we can Dec 18 23:18:51 khem: let me share my hacks Dec 18 23:18:55 and automake always outsmarts me Dec 18 23:18:59 sure Dec 18 23:19:10 khem: I'm not running into automake, I've beaten that Dec 18 23:20:26 maybe we can use newlib to bootstrap Dec 18 23:21:43 khem: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=9640c4d25019188b9c69eb9b5b286ba287dd82fc builds and appears to work (drop glibc-initial) Dec 18 23:21:54 khem: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=d51b162ee82ae2a4e2ed0a04006c959850f17620 doesn't work Dec 18 23:22:42 khem: fails in glibc with missing liggcc_eh.a which is because I'm using the posix compiler with a "single" libgcc I hacked the makefiles to get Dec 18 23:23:24 create a symlink for libgcc_eh.a pointing to libgcc.a Dec 18 23:23:24 khem: I did see the note at the bottom of http://www.linuxfromscratch.org/lfs/view/6.5/chapter05/gcc-pass1.html about a symlink but that causes assertion failures which can't be goof Dec 18 23:23:43 khem: I tried that, assertion failures Dec 18 23:24:11 derRichard: patch to openembedded-core@lists.openembedded.org please Dec 18 23:24:38 khem: frustrating as its close... Dec 18 23:24:46 or feels like it anyway Dec 18 23:25:14 are we usign --disable-shared Dec 18 23:25:33 khem: for libgcc-initial, yes Dec 18 23:25:59 rburton: ups :) Dec 18 23:26:04 thats the reason that eh .a is not created Dec 18 23:26:12 its ok to symlink it Dec 18 23:26:29 glibc does not need any obects which are outsideof libgcc.a Dec 18 23:26:49 eventually we will have libgcc_s.so to do unwinding and eh Dec 18 23:26:55 rburton: why is poky@ wrong? the patch targets git://git.yoctoproject.org/poky Dec 18 23:26:58 later in build Dec 18 23:27:02 khem: then I guess there is some other problem causing the assertions Dec 18 23:27:16 point me to assertions Dec 18 23:27:26 derRichard: blame RP (because poky is just bitbake+oe-core+others glued together) Dec 18 23:27:43 poky is a Japanese food Dec 18 23:27:49 * khem leave to pick kids Dec 18 23:28:04 rburton: ok :) Dec 18 23:28:16 khem: https://pastebin.com/0B4F9si3 Dec 18 23:28:30 * RP is always to blame Dec 18 23:29:14 khem: was using mips as I didn't have it in the local cache Dec 18 23:29:16 khem, poky is Hawaiian !! Dec 18 23:29:36 armpit: pokey was a sweet from tokyo (iirc) Dec 18 23:29:59 rburton: pocky ;-) Dec 18 23:30:06 bah close Dec 18 23:30:18 patch sent Dec 18 23:30:22 * derRichard needs some sleep Dec 18 23:30:36 gn8 guys and thanks for all your help! Dec 18 23:30:42 derRichard: thanks! Dec 18 23:36:43 sorry poke.. all sounds the same Dec 18 23:36:52 https://en.wikipedia.org/wiki/Poke_(Hawaiian_dish) Dec 18 23:40:07 * paulg has nightmare flashbacks to peek/poke in Commodore Basic. Dec 18 23:43:05 paulg: seems to be a day for flashbacks Dec 18 23:44:39 * RP was spectrum basic Dec 18 23:45:12 * paulg was Commodore C=64 basic Dec 18 23:57:42 khem: would you believe that could be broken ifunc support on mips... Dec 18 23:58:03 it just compiled. /me looks at it sceptically Dec 19 00:12:50 khem: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=b46c82c5f5cb6f5ad64d4533391fbd9f08392f74 appears to build. Will continue to poke at it as its got potential Dec 19 02:01:18 RP: libc_cv_ld_gnu_indirect_function=no is not good it will disable ifunc support in glibc you can do it with --[en|dis]able-gnu-indirect-function Dec 19 02:04:28 but I think ifunc makes same glibc compiled optimized across multiple machines Dec 19 02:04:41 for OE it may not matter as much but for x86 it may Dec 19 02:05:31 and why do we need --with-glibc-version=2.28 ? Dec 19 02:13:27 zeddii: Can you include https://lkml.org/lkml/2018/12/11/1275 patches in your 4.19 kernel headers pull please ? Dec 19 02:14:18 zeddii: this will untwist the arm64/musl builds a bit and we will get libunwind and other ptrace using packages goinf Dec 19 02:14:57 yup. I can do that. I may just jump 4.19 for the libc headers and go right to 4.20, so it’ll be in there as well I hope. hmmm. or not, since it is new. either way. yah. I’ll make sure it is applied and in the testing I just started. Dec 19 02:14:58 zeddii: mostly this should go into kernel upstream without many changes Dec 19 02:15:19 hehe. cool. so no problem. I’ll include it directly and watch the upstream process. Dec 19 02:15:21 I think 4.21 is mostly where it will show up Dec 19 02:15:32 fantastic Dec 19 02:15:41 yah. since linus wants to release this week, it won’t make 4.20, I’ll catch it on .21 Dec 19 02:15:54 yep Dec 19 02:16:15 this will ensure musl/aarch64 will be at par with x86_64 in world builds Dec 19 02:16:28 in musl Dec 19 02:16:43 and also will fix riscv64 **** ENDING LOGGING AT Wed Dec 19 03:00:01 2018