**** BEGIN LOGGING AT Thu Jun 15 03:00:03 2017 Jun 15 06:44:09 seebs: log sent Jun 15 06:44:47 denix: as khem mentions we do remove RPATHS in the search path and we do use our own interpreter Jun 15 07:13:05 Hi, I'm trying to figure out how I can pinmux under yocto. I need to activate the adcs and some pwm outputs. I managed to do that under debian with 2 different ways but I cant seem to find a good example to do that under yocto. Has anybody done that before or has an example that they would share? Jun 15 07:14:59 morning all Jun 15 07:30:59 good morning Costin1, and good afternoon in my time Jun 15 07:31:11 :) Jun 15 07:31:30 the beauty of being scattered arround the world Jun 15 07:31:34 Does anyone use meta-raspberry before ? Jun 15 07:32:12 Good Morning =) Jun 15 07:33:03 I'm thinking porting it to S3C6410 since they are based on ARM1176JZF-S based CPU Jun 15 07:33:43 and my RPi is doing something already now =), that's why I want to try yocto with my FriendlyARM Jun 15 07:33:59 Blue_ : what do you mean by " pinmuxing in yocto " ? You meaning seeting variables before building to set "correct" dts?? Jun 15 07:36:47 something with : meta-raspberrypi/conf/machine/include/tune-arm1176jzf-s.inc must be changed following S3C6410, correct me if I'm wrong ? Jun 15 07:37:51 and does linux.yocto 4.10 kernel support it ? it will make my life abit easier if it does.. Jun 15 07:39:37 it's for bcm2708-rpi-0-w.dtb ==> device tree...where can I see those device tree files...?/etc/... ? Jun 15 08:22:54 I need to activate PWM, ADC and SPI with a dts file but I cant seem to find the correct place to add them. Can I only add them in the build process or can I activate them after the build if I add them to the uEnv and place the file in the correct folder? Jun 15 08:51:05 I can see : http://git.yoctoproject.org/cgit.cgi/linux-yocto-4.9/tree/arch/arm/mach-s3c64xx Jun 15 08:51:14 how can I use that for the board ? Jun 15 08:52:50 rick_0: configure the kernel to target that machine - see the BSP manual for how to create a new BSP that does that (as pointed to in the reply to your email on the mailing list, at least I assume it was yours) Jun 15 08:54:04 hello. How a recipe selects what header files will put to a dev package. Because I see that include folder has eg 10 header files. But only 4 of them installed to sysroot and SDK and not all. Why is that? Jun 15 08:54:30 In the recipe I couldn't find a difference between those header files Jun 15 08:55:09 this book : Board Support Packages (BSP) - Developer's Guide ? Jun 15 08:58:12 rick_0: yes - here's the current link, since google can find much older ones: http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Jun 15 08:58:57 Tamis: which include folder are you looking at that has the 10 files in it? Jun 15 09:00:39 bluelightning: ok eg /tmp/work/ppce500v2-qoriq-linux-gnuspe/openldap/2.4.44-r0/openldap-2.4.44/include/ has about 40 header files Jun 15 09:01:06 bluelightning: but only some of them are installed to SDK and sysroot Jun 15 09:01:30 bluelightning: And I cannot understand the distinguish Jun 15 09:02:08 Tamis: what about /tmp/work/ppce500v2-qoriq-linux-gnuspe/openldap/2.4.44-r0/image/usr/include/... ? Jun 15 09:02:23 (I'm assuming that'll be the reduced subset) Jun 15 09:03:33 bluelightning: indeed the files there are less Jun 15 09:03:36 only 9 Jun 15 09:03:46 what is the reduced subset? Jun 15 09:04:01 bluelightning: and how is this set? in bb file? Jun 15 09:05:57 bluelightning : ok, thanks Jun 15 09:08:17 Tamis: this would be controlled by however the do_install step is defined... that could be in the recipe or it may simply be what "make install" for the software the recipe is building does Jun 15 09:08:45 share experiment, it seems that chromium working ok with xfce, my compile is nearly finished for qemux86-64 Jun 15 09:10:01 Tamis: looking at the recipe I suspect this is under the control of "make install" Jun 15 09:10:42 bluelightning: hhmm. I suspect that either. I going to have a look at the Makefile Jun 15 09:10:51 Tamis: bear in mind that some of the files under /include in the source tree may be internal headers that are not intended to be used by external applications Jun 15 09:12:04 bluelightning: Thanks a lot for the help Jun 15 09:12:11 Tamis: no problem Jun 15 09:12:18 bluelightning: I will have in mind Jun 15 09:49:53 what do i need for qt with libinput and a touchscreen ?? Jun 15 11:19:23 ed2: around? I'm trying to determine whether the filename extension for wic changed at some point? looking at a krogoth build's output we don't seem to have any .wic files published Jun 15 11:20:26 no, it was 'wic' from the very beginning as far as i remember. Jun 15 11:20:37 well, at least for 'wic' image type. Jun 15 11:21:18 probably in krogoth wic image type was not enabled by default, so no images were generated. Jun 15 11:23:26 yeah krogoth didn't have wic enabled, i'm 99% sure Jun 15 11:38:36 interesting, I'll follow up on that after lunch Jun 15 11:38:46 thanks ed2, rburton Jun 15 11:46:46 I'm looking for a way to extend populate_sdk to add some custom binaries to toolchain (to be used for cross compilation for images and as SDK on host machine) Jun 15 11:46:46 (The binary recipe uses bin_package) Jun 15 11:46:46 My idea was to extend TOOLCHAIN_HOST_TASK @ ./meta/classes/populate_sdk_base.bbclass - (yes this is a temporary hack to check if it works) Jun 15 11:46:46 But then when executing bitbake -c populate_sdk I see: Jun 15 11:46:46 No package ldr-utils available. Jun 15 11:46:47 Error: Unable to find a match Jun 15 11:46:47 Is this a recommended way? Jun 15 11:48:20 the native bits in a SDK need to be built for the sdk Jun 15 11:48:37 so you need to BBCLASSEXTEND=nativesdk in the recipe, and add nativesdk-ldr-utils to the variable Jun 15 11:49:46 :-) Jun 15 11:50:25 rburton: Thanks, I will check that Jun 15 12:24:11 ../util-linux-2.28.1/schedutils/chrt.c:88:17: error: ‘__NR_sched_setattr’ undeclared (first use in this function), Seeing this issue while bitbake Jun 15 12:31:19 rburton: ed: ah, so the .wic artefacts are generated by the bitbake when there's wic in IMAGE_TYPES? and manually invoking wic generates .directdisk files? Jun 15 12:35:26 error: ‘__NR_sched_setattr’ undeclared (first use in this function), Seeing this issue while bitbake. Jun 15 12:35:42 has anyone faced similar issue? Jun 15 12:48:28 Ramose: this may be useful perhaps: https://stackoverflow.com/questions/41257902/util-linux-2-28-1-schedutils-chrt-c8817-error-nr-sched-setattr-undecl Jun 15 12:49:30 RP: rburton: how goes M1 stabilisation? I'm assuming my bitbake patch last night won't make M1? Jun 15 12:50:26 joshuagl: it was built yesterday afternoon Jun 15 12:50:47 RP: thanks! definitely missed then :-) Jun 15 12:51:01 joshuagl: yes Jun 15 13:42:37 rburton: Unfortunately the same error Jun 15 13:43:25 It is now present at: Jun 15 13:43:25 ./tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-ldr-utils Jun 15 13:43:31 which is I think correct Jun 15 13:46:33 yes, for host stuff in a sdk Jun 15 13:56:26 RP: I have sent my set of patches to the oe-core list now. Would appreciate if you can run it through the autobuilders to see if I have missed anything... Jun 15 14:08:27 rburton: ed: is it true that the .wic artefacts are generated by bitbake when there's wic in IMAGE_TYPES? and manually invoking wic generates .directdisk files? trying to understand if we have a problem building krogoth on the AB Jun 15 14:10:26 joshuagl: that's true Jun 15 14:10:34 thanks ed2 Jun 15 14:22:08 RP: world builds with hardening rework for all qemus comes out clean for musl and glibc Jun 15 14:23:28 ovmf is one erratic package that fails on i586 alone sometimes due to some internal tool bailing out, Jun 15 14:23:31 khem: I assume you have no objection to removing the uclibc bits from OE-Core? Jun 15 14:23:39 khem: cool on the hardening Jun 15 14:23:40 Not at all Jun 15 14:24:13 RP: I would even propose to remove glibc :) Jun 15 14:24:43 well that was in lighter vein Jun 15 14:24:52 khem: :D Jun 15 14:25:16 but I think we should be able to world builds for all qemu machines on musl too Jun 15 14:25:52 khem: nice. We could never do that with uclibc :) Jun 15 14:25:53 during this excercise -c testimage core-image-sato succeeded for all qemu machines Jun 15 14:25:55 on musl Jun 15 14:26:00 very cool Jun 15 14:26:27 so if there was a builder lying vacant we could increase the coverage for musl Jun 15 14:26:52 khem: there are many many demands on test coverage :( Jun 15 14:27:08 due to less header clutter the builds with musl are faster too Jun 15 14:27:10 khem: its about how long it takes to get changes into master Jun 15 14:27:22 khem: more tests means longer patch turnaround Jun 15 14:28:10 yes I see that as downside Jun 15 14:28:51 however, I think if you consider the full code flight then it will be faster for sure Jun 15 14:29:06 since just getting into master doesnt mean anything really Jun 15 14:29:30 you can commit a patch without any testing in 1 second Jun 15 14:30:21 world is moving more towards devops model and developers are enagaged till the field deployment and they also get to see how customers are benefitting/suffering from their work Jun 15 14:31:01 so for that we have to do a lot of testing before accepting a patch Jun 15 14:31:45 ideally a full CI/CD pipeline would be my dream Jun 15 14:32:23 that would also mean no more point releases Jun 15 14:32:39 future is rolling releases with CI/CD Jun 15 14:37:29 khem : As a student, i'm curious of how can be replace ulibc and glibc ? Are they really necessary? How can we do without ? Jun 15 14:39:25 ChrysD_: we still need a system C library so we have a new impl called musl prounced as 'muscle' Jun 15 14:39:43 khem : what does it allow? Jun 15 14:40:11 which is implemented from scratch and sticks to posix primarily Jun 15 14:40:33 so its gotten away from hideous extentions which make programs non portable Jun 15 14:42:09 khem : in which way Glibc is hideous? Jun 15 14:43:41 glibc has grown over many years, musl is new and learnt lessons Jun 15 14:43:43 it has implemented extentions which were probably needed at the time when they were done but apps started to use them Jun 15 14:44:15 rburton: btw. I just rebased kraj/hardening-fixes dropping sanitizer patch Jun 15 14:44:35 and adding webkitgtk patch Jun 15 14:44:56 thanks Jun 15 14:45:27 look at ftw impl obstack impl they are purely glibc extentions Jun 15 14:45:45 rburton : and the fact that it have been made for specific need make him a little more obselete by the fact that for nowdays need it needs to change lot of things so that was easier to start it from scratch like musl? Jun 15 14:45:49 now I look systemd is doing same think become sink for everything Jun 15 14:47:14 ChrysD_: the development has moved quite high on s/w stack that libcs hardly matter Jun 15 14:47:48 e.g. if you use docker then the default supported images are using musl but folks hardly know that Jun 15 14:48:35 this also means that one would like to save resources spent on commonditized pieces Jun 15 14:56:20 khem : i really need to learn more ahah Jun 15 14:58:04 khem : I get into trouble to understand in deep what is going on. Between POSIX, standard C, libc etc Jun 15 14:58:38 good news is that standard C and posix API are publically available if you google for them Jun 15 14:59:30 musl implements just those, glibc throws the kitchen sink in plus years of technical debt/cruft. glibc is certainly more featureful and the default but musl is catching up *fast* Jun 15 14:59:31 khem : I have also some difficulty to understand the fact that we need to put a kidn of C POSIX Library... But i guess sytems are evolving with time which make the need of evolving also the C POSIX Library, but i guess it a challenge to make new standard C library that fit for news system and also still being compatible for older POSIX api. Jun 15 15:01:30 rburton : Yeah and i have curiously google them but i don't have enough software experience background and also on hardware systems to be able to have my opinion Jun 15 15:01:52 ChrysD_: It is the other way around: musl is POSIX compliant, glibc implements POSIX plus a lot of glibc extensions... Jun 15 15:02:48 Saur : But if glibc implements POSIX, it still compliant for POSIx applications. As a noob i would say that glibc extensions should not interact with POSIX applications. Jun 15 15:03:20 correct Jun 15 15:03:30 ChrysD_: The problem is that developers are not aware what is POSIX and what are glibc extension, and thus end up using the extensions without realizing. Jun 15 15:03:39 but its extra code paths to be in memory, tested, have bugs, etc Jun 15 15:04:49 Saur : So you have the choice between a standard lib C totally compliant for POSIX which make reduction of lot of bugs but can't do let's stuff. Or doing a standard C compliant to POSIX with extensions for some other case and make it rich of features but which include more bugs/errors Jun 15 15:05:02 can't do some stuffs* Jun 15 15:05:51 But if everyone is posix compliant, there is more luck of not having integration problems i guess Jun 15 15:08:16 But I guess, with the development of 64 bits machine, there is a need to modify POSIX no? Because the way as the things are made have been thinking because of actual hardware architecture. Jun 15 15:08:28 not really Jun 15 15:11:42 rburton : No optimization problems ? I guess posix have been made in a time which steps/tasks have been divided in units which can be handle by the hardware but more technology evolve, more the architecture can change no? When you can do something in 64 bits instead of 32 or 16, it allow you to do things differently? Jun 15 15:11:48 the whole point of posix is to have a standard interface regardless of hardware, unix systems have supported numerous architectures for decades Jun 15 15:11:53 and 64 bit isn't new Jun 15 15:13:46 ChrysD_: thats all a compiler proble Jun 15 15:13:53 problem Jun 15 15:13:58 rburton ok Jun 15 15:22:26 khem: if you could rebase yuor series to master-next that would be great, Richard just pushed some stuff that conflicts with your security flags Jun 15 15:24:07 ChrysD_: posix is always evolving OS std, you seem to pin it to a point in time history which is not the case Jun 15 15:24:23 rburton: arghh ok let me see Jun 15 15:24:31 sorry :) Jun 15 15:28:43 rburton: done and pushed, its the uclibc drop some of my own sins from past Jun 15 15:28:51 :) Jun 15 15:28:53 thanks Jun 15 15:30:38 RP: yes, own interpreter was always the case, but I missed the RPATH removal change. and the issue I was debugging looks like host libraries are being loaded instead of toolchain ones, so I started suspecting RPATH... Jun 15 15:31:16 actually some of GNU extentions has progressed into posix or ISO C standards eventually which is all good, however some has been added and conflicted with gnu extentions e.g. inline semantics Jun 15 15:31:19 major PITA Jun 15 15:31:36 denix: my chief suspect might be the wrong dynamic loader being used. have you checked the interpreter section to see its using the right one? Jun 15 15:31:40 and some printf formats like %m Jun 15 15:32:03 RP: he confirmed yesterday that its using the ldso from nativesdk-glibc Jun 15 15:32:25 so it kind of left me thinking that are there any version issues Jun 15 15:32:44 with libssl solib that gets encoded into the DT_NEEDED Jun 15 15:33:00 may be the problem really it on the system where the SDK was built Jun 15 15:33:11 khem: hmm. That shouldn't happen... Jun 15 15:33:18 sdk host is just replaying the problem Jun 15 15:33:26 may be Jun 15 15:34:00 RP: yes, PT_INTERP is fine Jun 15 15:35:05 RP: what khem is saying may be true - same sdk works fine on my system, but gives this issue with libssl on customer system Jun 15 15:38:31 there is solib version thats also checked before loading Jun 15 15:38:55 so you might have two different versions of libssl and it will know which one to load Jun 15 15:49:25 khem: I'll get him to collect more data about the system, unfortunately right now it's all remotely... Jun 15 15:49:25 Btw, are others seeing (or rather not seeing) missed emails on the openembedded-core list? I do not know if it is a problem with the mail list server, our company mail server, or something in between, but I have started to notice that I do not get all mails. Typically I get responses to mails I have never seen, or as just now, when I send a stack of patches to the list, I do not get all the patches back. I can see them in the mail archive on the web, and othe Jun 15 15:51:11 Saur: I did have problems for a while, never did figure out what was happening but I did talk to halstead about it Jun 15 15:54:31 Saur: if your company uses Symantec virus/spam filters suite, you may need to get them to whitelist the mailing lists you are using Jun 15 15:57:42 Saur, RP: we've had some issues like that recently too. apparently, Symantec beefed up their filters in wake of wannacry, but that started affecting public mailing lists... Jun 15 15:57:58 Saur: presumably you have the "do not send duplicate mails" mailing list option turned off? (it defaults to on IIRC) Jun 15 15:58:34 denix: No, we use Trend Micro, but I have actually checked the quarantined mails as well, and that is not where they end up. Jun 15 15:59:01 bluelightning: Hmm, no idea... Jun 15 15:59:41 Saur: ok, go to the listinfo page for the mailing list, hit "unsubscribe or edit options" and there are two switches there of possible interest Jun 15 15:59:59 "Avoid duplicate copies of messages?" Jun 15 16:00:11 and "Receive your own posts to the list?" Jun 15 16:00:40 if you have the mailing list filtered into a folder in your client like I do you probably want those set to No and Yes respectively Jun 15 16:01:03 wouldn't account for random messages going missing but it might cover part of the issue you describe Jun 15 16:02:36 bluelightning: Well, of the 12 patches (including the cover letter) I sent, I got 11. Interesting thing is that both when I sent the first stack and the second one after fixing the comments from rburton, it is the 01/11 patch that is missing... Jun 15 16:03:23 Saur: hmm, that is strange Jun 15 16:09:41 ed2: Hi. Is wic supposed to also create the mountpoint directory alonside the fstab entry, or just the fstab entry? In other words, should I create the mountpoint folder by myself? Jun 15 16:13:18 diego_r: you should. wic assumes it exists. Jun 15 16:15:28 ed2: thanks Jun 15 16:53:18 RP, khem: bah, he has LD_LIBRARY_PATH set! Jun 15 16:56:43 RP, khem: is that still checked first by our own ld.so loader? Jun 15 17:00:47 yes it is Jun 15 17:00:49 denix: it will be Jun 15 17:00:56 denix: that would explain it Jun 15 17:02:11 RP, khem: looks to me as misconfigured host system... Jun 15 17:05:24 denix: sounds like it Jun 15 17:05:33 kergoth: have to love a reference to "gcc/gcc_3.4.0.oe" Jun 15 17:05:50 kergoth: That predates me :) Jun 15 17:21:30 RP: haha, wow. i remember working on those. where's it referenced? Jun 15 17:22:12 denix: the order for our nativesdk ld.so is LD_LIBRARY_PATH then RPATH then linker defaults then ld.so.cache Jun 15 17:22:26 kergoth: top of meta/recipes-core/glibc/glibc-package.inc Jun 15 17:22:45 ha Jun 15 17:22:54 khem: thanks Jun 15 17:23:22 we swapped the last two meaning look for linker defaults before ld.so.cache Jun 15 17:23:50 so they should be removing or may be SDK setup script should clean up LD_LIBRARY_PATH Jun 15 17:24:02 * RP can't quite decide how much of the remaining uclibc bits to kill Jun 15 17:24:38 RP: wipe it clean :) Jun 15 17:24:47 khem: funny how the issue was actually on the surface... Jun 15 17:25:15 khem, denix: I'd take a patch to make the SDK setup script error if LD_LIB is set Jun 15 17:25:17 denix: yeah sometimes its hard to extract the right bits of information Jun 15 17:25:55 RP: should it clean it or just complain? Jun 15 17:26:06 denix: error and make the user fix it Jun 15 17:26:08 I would just clean and complain Jun 15 17:26:15 at same time Jun 15 17:26:21 denix: we can't guarantee what the right fix would be, their system may need it to work Jun 15 17:26:55 hardly ever the case RP Jun 15 17:27:21 khem: maybe not but we open ourselves to bugs that way. Most of our philopsohy is to error and suggest a fix Jun 15 17:27:25 but I get it, we should not be cleaning others mess, just point it out Jun 15 17:28:16 yeah, when there's a clear solution that wno't break anything else, we should fix and warn, but if the answer is unclear or could have unforeseen consequences, not so much Jun 15 17:28:18 "Your environment is broken, you probably need to "unset LD_LIBRARY_PATH" but please check why this was set in the first place and that its safe to unset. The SDK will not operate correctly with this set." Jun 15 17:28:19 RP, khem: I see there are some custom bits there, along with system paths. should we check for only system paths or just LD_LIBRARY_PATH being set in general? Jun 15 17:28:41 denix: I'd check for it set at all, they really don't want that Jun 15 17:29:05 denix: if they really do, they know enough to bypass the check ;-) Jun 15 17:29:38 We've had these uclibc gcc patches since forever Jun 15 17:30:43 RP: ok, makes sense Jun 15 17:34:55 hmm, some software packages out there suggest adding their paths to LD_LIBRARY_PATH - e.g. http://staf.sourceforge.net/ (Software Testing Automation Framework), http://staf.sourceforge.net/current/STAFInstall.pdf has a sample startup script, which I guess people end up sourcing globally at boot :( Jun 15 17:36:47 * paulg thought staf was a virus.... Jun 15 17:37:18 paulg: heh :) Jun 15 17:38:03 denix: hmm. Hardly best practise :/ Jun 15 17:38:34 denix: detecting what may be a system path is hard too :( Jun 15 17:41:50 RP: yeah, I'd have to agree Jun 15 18:32:09 denix: I think we insert ourselves pretty well on path side of things but it wouldnt hurt to check and let user know that his PATH variable is a bit awkward Jun 15 18:32:28 shlibs issues are more subtle Jun 15 18:32:41 unless some binaries are doing exec on /usr/bin/foo Jun 15 18:32:51 then you are out of luck without patching the package Jun 15 18:33:21 I must admin that new firefox release is quite nice Jun 15 18:33:54 chrome says 45% energy impact on my mac, and doing same activity ff says 26% Jun 15 18:34:18 yikes Jun 15 18:34:37 yeah chrome is hog to say the least Jun 15 19:12:52 RP, khem: http://lists.openembedded.org/pipermail/openembedded-core/2017-June/138295.html Jun 15 19:18:04 denix: looks good to me at a quick glance! Jun 15 19:57:56 date Jun 15 20:13:53 Hello - is there a way for one bitbake recipe to call update-rc.d on two initscripts? (krogoth-15.0.0-32-g898a783) Jun 15 21:48:53 khem: does musl still use libargp? Jun 15 22:21:15 thinking about splitting up meta-sourcery into meta-external-toolchain and meta-sourcery, so the latter only contains the bits truly specific to the sourcery g++ toolchain, and the former has the generic configuration and sysroot extraction Jun 15 22:21:34 hmm Jun 15 22:21:53 would make it easier for someone wanting to use it as an example, since it'd be clear what they should copy and what not Jun 15 22:22:24 kergoth: that could be useful Jun 15 22:24:14 * RP is finding deleting things therapeutic Jun 15 22:25:37 not sure if http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss2&id=91202a333afbc7da704f85f3bb61d80caf1468c0 goes too far (insane and site uclibc pieces) Jun 15 22:26:09 Equally there is some stuff which is just horrible like those pciutils patches where a patch patches another one :/ Jun 15 22:38:41 RP: yikes Jun 15 22:38:49 I do have a foo.bb, which has BBCLASSEXTEND = "nativesdk" Jun 15 22:38:49 It can be built with Jun 15 22:38:49 bitbake foo and bitbake nativesdk-foo Jun 15 22:38:49 Is there any way to force it to be built with bitbake nativesdk-foo? Jun 15 22:40:07 lukma: rename the recipe to nativesdk-foo.bb, remove BBCLASSEXTEND, add 'inherit nativesdk' Jun 15 22:43:36 RP: yes Jun 15 22:44:36 RP: also remove kconfig-frontends recipes thats was added for eglibc Jun 15 22:45:09 khem: there are a couple of things I could probably use your eyes on... Jun 15 22:45:20 sure Jun 15 22:46:55 khem: not sure if recipes-support/gnutls/gnutls/correct_rpl_gettimeofday_signature.patch is needed, or recipes-support/rng-tools/rng-tools/0001-If-the-libc-is-lacking-argp-use-libargp.patch os the systemd uclibc pieces (recipes-core/systemd/systemd/0006-configure-Check-for-additional-features-that-uclibc-.patch, recipes-core/systemd/systemd/0009-util-bypass-unimplemented-_SC_PHYS_PAGES-system-conf.patch, recipes-core/systemd/systemd/0008-nspawn-Use-ex Jun 15 22:47:27 or perhaps recipes-bsp/usbutils/usbutils/iconv.patch Jun 15 22:49:56 khem: patch to drop kconfig-frontends is queued Jun 15 22:51:25 rpl_gettimeoftheday can go Jun 15 22:53:28 recipes-support/rng-tools/rng-tools/0001-If-the-libc-is-lacking-argp-use-libargp.patch is needed by musl Jun 15 22:54:00 recipes-core/systemd/systemd/0006-configure-Check-for-additional-features-that-uclibc-.patch can go Jun 15 22:54:16 recipes-core/systemd/systemd/0009-util-bypass-unimplemented-_SC_PHYS_PAGES-system-conf.patch can ho Jun 15 22:54:18 go Jun 15 22:54:48 recipes-core/systemd/systemd/0008-nspawn-Use-execvpe-only-when-libc-supports-it.patch can go Jun 15 22:57:17 khem: thanks, I'll queue those in the test queue :) Jun 15 22:57:45 khem: I pulled the obvious binutils/gcc ones, if you see any others I've missed... Jun 15 22:58:25 openssh had some uclibc tweaks IIRC Jun 15 22:58:30 have you unplugged those Jun 15 23:00:06 khem: I think so. There are a number of uclibc refs left but I think the rest are needed by musl Jun 15 23:01:34 RP: once we decide to switch target arch for qemuarm you will have another wave of arm cruft that you can now remove Jun 15 23:02:45 RP: you did not remove gcc/uclibc patches it seems yet Jun 15 23:03:38 khem: one second, let me refresh -next Jun 15 23:03:44 ah i see there are series of patches Jun 15 23:04:27 khem: try master-next now Jun 15 23:04:43 khem: there are three patches, chipping pieces out Jun 15 23:04:56 khem: kept deciding to dig deeper Jun 15 23:05:26 khem: not sure we can drop armv5 support quite so easily Jun 15 23:06:18 0020-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch probably can be modified to change just glibc ld.so Jun 15 23:06:27 but its ok as it is prolly Jun 15 23:07:46 let me rebase on master-next and do a musl build Jun 15 23:08:51 khem: I haven't tested that last patch so thoroughly yet, testing is welcome though :) Jun 15 23:13:00 last patch is ok nothing on oe-core needs kconfig-native Jun 15 23:16:45 I think most of problems will be with musl if any Jun 15 23:16:57 otherwise your changes look ok to me Jun 15 23:18:29 khem: cool, I'll do some testing locally, then on the AB and take it from there thanks Jun 15 23:19:16 fired my local build on top of your master-next Jun 15 23:19:47 its going to take couple of hrs to finish the world build it seems to be rebuilding everything Jun 15 23:21:05 I will leave you a message or a patch if I find something odd Jun 15 23:21:44 khem: it changes binutils so most things will rebuild. Sounds good thanks! Jun 15 23:22:45 yeah I was kind of stupidly hoping for sstate to come from heaven :) Jun 15 23:33:23 khem: need that quantum computer which computes all possible sstates and then collapses the computation into the right sstate through the act of observation :) Jun 15 23:33:48 I will let google know of our requirements Jun 15 23:34:28 in short we only need a DWIM ( Do what i mean ) button Jun 15 23:35:03 absolutely :) Jun 15 23:35:07 * RP -> Zzzz Jun 15 23:35:32 gn **** ENDING LOGGING AT Fri Jun 16 03:00:03 2017