**** BEGIN LOGGING AT Fri Feb 16 03:00:02 2018 Feb 16 04:46:12 hello Feb 16 05:10:40 New news from stackoverflow: Bitbake meta-toolchain-qt5 - UnicodeDecodeError - imagine my surprise Feb 16 05:21:23 hello Feb 16 05:21:26 anyone awake ? Feb 16 05:21:45 question: how can i trigger regnerate sdk from 0 ? Feb 16 05:22:11 there is only one command i see, bitbake bla-bla-name -c populate_sdk Feb 16 05:22:35 i'm having some issues , that SDK missing files, I want to some how clean just the SDK stuff, and ask it to regenerate it afresh Feb 16 05:22:40 tried with -f flag Feb 16 05:22:43 didn't solve it for me Feb 16 06:18:59 Hi, I am trying to fetch from company git. No matter what I do it won't fetch anything. No warnis or errors. I have googled and trie ssh ... you name it. Any ideas Feb 16 06:35:02 https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy Feb 16 06:42:08 Before going to that. Git load lisence file and checs it ok but nothing else. Feb 16 08:02:07 ok, thats the best bitbake error message ever. ERROR: Nothing RPROVIDES 'bigbuckbunny-1080p' Feb 16 09:01:26 seebs: it seems as though the fix you made also fixes the epoll hang (just doing a bit more testing to confirm this) Feb 16 09:32:33 seebs: yes it does, thanks! can you look at the remaining patches to see if any of them can be merged to pseudo repo? Feb 16 11:10:28 I often create paches for the same recipe using `devtool modify` and use `devtool reset` to disable the workspace and test the patch in a final build. However, when running `devtool modify` again it complains the path already exists and is not empty. Feb 16 11:10:34 See https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe Feb 16 11:11:38 Is there a better workflow that allows to re-enable a workspace in a clean state? Feb 16 11:17:31 Since the recipe is a git repo containing linux kernel sourcecode I don't want to clone it over and over again Feb 16 12:40:23 hello Feb 16 12:42:05 New news from stackoverflow: Howto generate a Yocto image with spanish full-support by default Feb 16 12:42:25 hey anyone awake here ? Feb 16 12:42:34 nope. i'm so totally asleep! Feb 16 12:42:40 :O Feb 16 12:42:41 mee, too Feb 16 12:42:51 hey, i got a question Feb 16 12:43:01 i got one too! lets swap, ok? Feb 16 12:43:16 how can I clean everything for SDK target Feb 16 12:43:21 and re-make it from 0 Feb 16 12:43:43 so if I do this to generate it , bitbake bla-bla-name -c populate_sdk Feb 16 12:44:02 is there some clean command that can clean this ? Feb 16 12:44:33 probably be cleaning the image, but its just a guess. Feb 16 12:44:41 entire image ? Feb 16 12:44:51 i don't want to .. Feb 16 12:46:21 hum. if you do just clean the image, it does just reassemble it. not recompile everything. Feb 16 12:46:53 so it won't delete all compiled ? Feb 16 12:46:57 that would be hours .. Feb 16 12:47:02 no why should it? Feb 16 12:47:08 bitbake -c clean your-image Feb 16 12:47:12 becaause I don't know Feb 16 12:47:20 and then rebuild it. the sstate should be totally preserved Feb 16 12:48:20 al' right Feb 16 12:48:37 let me try .. having issues with SDk not being generated correctly after something happen Feb 16 12:49:40 I did just very small changes, like add extra library to target, and enlarged boot partition. and somewhere along the line SDK stopped being generated correctly. it still getting generated, but it's missing some files Feb 16 13:26:52 seppe: devtool modify has an option to reuse existing source tree Feb 16 13:29:18 am i mistaken, or is this biting us? https://mail.python.org/pipermail/distutils-sig/2017-October/031712.html Feb 16 13:29:22 even on current head? Feb 16 14:08:13 kanavin: Ow, I see. Turns out there is a --no-extract / -n option, but it is not explained verry well in the "options" list (though there is an explanation in the beginning of the help). Feb 16 14:08:17 kanavin: thanks Feb 16 14:13:04 Anyone know the bootloader used by Yocto for Raspberry Pi? Feb 16 14:13:09 Is it Grub? Feb 16 14:14:09 philby: should be u-boot Feb 16 14:14:30 philby: https://git.yoctoproject.org/cgit.cgi/meta-raspberrypi/tree/recipes-bsp/u-boot/u-boot_%25.bbappend Feb 16 14:15:21 Thanks for the pointer LetoThe2nd Feb 16 14:19:36 $ bitbake-layers show-recipes | grep u-boot Feb 16 14:19:37 Parsing recipes..done. Feb 16 14:19:39 u-boot: Feb 16 14:19:40 u-boot-fw-utils: Feb 16 14:19:42 u-boot-mkimage: Feb 16 14:19:59 $ bitbake-layers show-recipes | grep -i grub Feb 16 14:20:01 Parsing recipes..done. Feb 16 14:20:02 grub: Feb 16 14:20:04 grub-efi: Feb 16 14:20:24 sigh! Feb 16 14:24:48 $ bitbake -e u-boot | grep "^PACKAGES=" Feb 16 14:24:50 ERROR: Nothing PROVIDES 'u-boot' Feb 16 14:24:51 ERROR: u-boot was skipped: Either UBOOT_MACHINE or UBOOT_CONFIG must be set in the raspberrypi3-64 machine configuration. Feb 16 14:25:01 I have a strong feeling that it is grub that's being used. Feb 16 14:27:10 you did not specify pi 3 nor 64 bit so far. in that case, it could very much also be grub. no idea. Feb 16 14:28:08 Sorry about that LetoThe2nd. It is RPi3 and build for 64 bit. Feb 16 14:35:14 in master, does exist a replacement for the missing yocto-layer script? Feb 16 14:42:03 and why it has been removed? Feb 16 14:43:14 mckoan: bitbake-layers Feb 16 14:50:45 rburton: thx Feb 16 15:50:04 kanavin: I can look at the others. I think we should probably at least try dropping the massive retry patches, I think those were a fix for a problem that should have been fixed other ways by now. Feb 16 15:51:46 I should probably use LDFLAGS separately from CFLAGS, which would fix the -fpie thing. Feb 16 15:52:22 And the "too many files deadlock" patch obviously goes away with epoll. Feb 16 15:52:39 hang on Feb 16 15:53:16 epoll isn't on by default, did you turn it on again before testing that? If not, we're still in the "too many files deadlock" case. Feb 16 16:12:45 New news from stackoverflow: Removing busybox completely from a Yocto generated image Feb 16 16:46:49 joshuagl, do you know if we build arm64 multilib in the AB? Feb 16 16:53:14 armpit: we can now look at http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/config.json and see there is only one arm64 build Feb 16 16:53:24 armpit: I believe we only build mips64 and x86_64 multilib on the AB Feb 16 16:53:30 armpit: so no, we don't Feb 16 16:53:34 k Feb 16 17:01:35 seebs: maybe that's what you've discussed with kanavin before I've joined, bu have you seen this? http://lists.openembedded.org/pipermail/openembedded-core/2018-February/147516.html Feb 16 17:12:16 rburton: RP good news ! I am able to reproduce the glibc UTF-8 issue Feb 16 17:12:30 bad news ! I have no idea why its happening Feb 16 17:12:31 khem: great! :) Feb 16 17:12:40 khem: ah :/ Feb 16 17:12:52 RP: I even tried new unibative tarball Feb 16 17:12:59 generated locally Feb 16 17:13:05 khem: didn't help? :/ Feb 16 17:13:08 nope Feb 16 17:13:20 khem: that was my best theory too :/ Feb 16 17:13:20 khem: what an emotional rollercoaster that was Feb 16 17:13:28 and I also tried to include own python2 in buildtools Feb 16 17:14:12 khem: does stracing it show anything interesting? Feb 16 17:14:20 I have to start using docker seriously as a result of this excercise Feb 16 17:14:40 my love for archlinux just doesnt fade away Feb 16 17:15:09 RP: so python2 is whats failing on the SDK Feb 16 17:15:31 there is a sanity check for UTF-8 and it just doesnt get it Feb 16 17:16:02 now, I have a hunch that the localedata from host is not readable by glibc 2.27 Feb 16 17:16:25 but to prove that I have to have a build system or sdk host which has glibc 2.27 Feb 16 17:17:38 so may be I should spin a debian testing docker container ... with own glibc 2.27 installed or something Feb 16 17:18:23 khem: That is something I've wondered, did the locales change in a way which means 2.27 can't read older ones? :/ Feb 16 17:18:53 some have Feb 16 17:20:26 see https://github.com/kraj/glibc/blob/master/NEWS#L117-L119 Feb 16 17:20:58 and https://github.com/kraj/glibc/blob/master/NEWS#L137-L154 Feb 16 17:21:19 khem: that sounds backwards compatible Feb 16 17:23:16 I think we should test include own locales in nativesdk-glibc Feb 16 17:23:21 and see if that changes anything Feb 16 17:24:27 khem: I know we've been torn on that issue in the past, the SDK gets large quickly one you start pulling a few in Feb 16 17:25:48 We should just think containers and get rid of these distro deps Feb 16 17:27:06 if we make container as API then a lot of these can be delegated to container and we will have to do less and less in SDK Feb 16 17:28:28 seebs: I tested your fix with and without epoll, and with all those extra patches Feb 16 17:28:30 I am a convert as you can sense :) Feb 16 17:28:46 seebs: I did not try to remove the patches and see what happens Feb 16 17:29:18 * armpit needs to start using containers for stable releases Feb 16 17:29:53 armpit: switch to my distro :) Feb 16 17:30:12 https://github.com/kraj/oe-build Feb 16 17:30:37 bitbake is nicely wrapped with dkr underneath Feb 16 17:30:58 you just do normal bitbake cmds and they run under container Feb 16 17:31:05 so seemless Feb 16 17:31:21 why not run everything in container? Feb 16 17:31:36 I still like my vscode editor Feb 16 17:31:49 I just bind 1 directory with the data and mount tmpfs inside Feb 16 17:31:51 khem, not sure if that will help with fc27 build failures on morty Feb 16 17:32:04 with all my customizations for other things Feb 16 17:32:21 ya, we've move to containers for all of the builds, and have been doing it that way for a while.. Feb 16 17:32:36 only way for us to build 'old releases' w/o something getting in the way.. Feb 16 17:33:03 * armpit can't help but get in his own way at times Feb 16 17:38:50 armpit khem /me misses the MV chroot days :P Feb 16 17:42:57 well containers are in a way chroots with facelift :) Feb 16 17:43:53 armpit: definitely, morty builds on newer distros these issues can then be ignored Feb 16 17:44:15 sure.. tell that to RP Feb 16 17:45:32 khem, have you played with ilp32 ? Feb 16 17:46:59 armpit: try documenting this for users :/ Feb 16 17:47:42 docker pull cbrake/oe-build and bitbake ... Feb 16 17:47:48 its quite easy :) Feb 16 17:48:35 * armpit yeah, last famous words Feb 16 17:48:51 * armpit it should work is another one Feb 16 17:50:31 when you do its a hack when I do its a workaround Feb 16 17:51:45 RP, maybe need to use emojs instead of words ? Feb 16 17:52:39 armpit: ;-) Feb 16 17:53:02 zeddii: I'm thinking I should perhaps abort 2.4.2 rc1 and wait for 4.12.20? Feb 16 17:54:17 * armpit its not in master Feb 16 17:56:08 * armpit I can play that game all day Feb 16 18:07:09 RP: uninative is only active on build hosts not on sdk hosts right ? Feb 16 18:10:25 khem: yes Feb 16 18:12:38 armpit: hmm :/ Feb 16 18:12:58 what Feb 16 18:13:23 so far as i know, the retries from 20->250 shouldn't be necessary Feb 16 18:13:43 also the diagnostic for the hang (which may be epoll-related) suggested an obvious one-line fix, which is now in master. Feb 16 18:14:35 RP: so in a way uninative is not involved in this case. becasue its trying to run a nativesdk binary Feb 16 18:15:06 or binary from native sdk host which is routed via nativesdk-glibc Feb 16 18:16:35 khem: hmm, right. Its related only in so much as both nativesdk-libc and uninative use libc relocation. I also thought the issues was happening in eSDK which does use uninative Feb 16 18:17:24 khem: I've not looked into that one in detail, I flagged uninative as it was eSDK Feb 16 18:17:28 * RP -> food Feb 16 19:13:23 New news from stackoverflow: How to export parent environment variable to bitbake shell task? Feb 16 19:43:28 New news from stackoverflow: Error when building Automotive Grade Linux Feb 16 22:12:43 Is Martin Jansa here? Feb 16 22:17:49 armpit: I have sent bunch of patches 3-4 weeks back for meta-oe, but I dont know your testing procedure, so do you use master-next for soaking patches or something else ? Feb 16 22:18:21 JPEWhacker: Martin hangs around here, but right now he is not here in room Feb 16 22:18:57 khem: Thanks Feb 16 22:26:20 armpit: I also have a patch for waf-samba in meta-oe that I need an update on.... I keep getting asked about it. **** ENDING LOGGING AT Sat Feb 17 03:00:00 2018