**** BEGIN LOGGING AT Mon Dec 03 03:00:03 2018 Dec 03 03:48:19 New news from stackoverflow: Kubernetes on Simatic IoT2040 Dec 03 08:13:24 laumann: :-) thanks for the heads up. Dec 03 10:33:39 rburton: I'd rather wait for meson 0.49, so that some patches can be dropped Dec 03 10:33:51 RP: sadly, no :( Dec 03 10:34:25 RP: very vaguely, there was something though Dec 03 10:34:31 kanavin: fair enough, just thought I'd ask. We had a spate of gpg memory allocation problems :/ Dec 03 10:36:04 kanavin: I'll probably just set the parallelism back a bit through the overall number of threads Dec 03 10:37:15 rburton: we have a couple more weird selftest fails overnight. One is a runqemu with no logs, the other is our mystery out of space problem Dec 03 10:38:02 Actual Rootfs size: 10208 Dec 03 10:38:07 RP: ah, now I remembered - we use --auto-expand-secmem, which previously helped Dec 03 10:38:13 yet | DEBUG: returning 9152 Dec 03 10:38:14 RP: argh that again arghghghgh Dec 03 10:38:23 * rburton -> drinking Dec 03 10:38:38 rburton: sorry :/ Dec 03 10:38:54 kanavin: are we still setting that? Is it possible it can get disabled somehow? Dec 03 10:39:01 kanavin: i saw you submit the g-i patches \o/ Dec 03 10:39:43 kanavin: btw, that dazzle failure disappeared when I dropped the g-i patch so there is something odd going on there Dec 03 10:41:52 RP: was the space thing on oe-selftest? Dec 03 10:42:04 rburton: yes Dec 03 10:42:28 RP: yes we are - see meta/oe/gpg_sign.py. However I am not sure if the option has the desired effect anymore. Dec 03 10:42:43 rburton, yep :) Dec 03 10:42:57 RP: I think there is a multilib-specific issue, I will look into it now Dec 03 10:42:58 kanavin: I'm wondering if something in configure might be able to disable it Dec 03 10:48:12 kanavin: Looking at gpg_args in that file, the pipe (|) looks a little odd? Dec 03 10:48:42 RP: I think it's gpg's undocumented hack to allow passing arguments to the agent Dec 03 10:50:37 kanavin: ah. I was just wondering if shlex does the right thing with it Dec 03 10:53:00 kanavin: I think its probably ok, just thinking out loud... Dec 03 10:53:21 Command '['/home/pokybuild/yocto-worker/oe-selftest/build/build-st-37321/tmp/work/core2-64-poky-linux/ncurses/6.1+20181013-r0/recipe-sysroot-native/usr/bin/rpmsign', '--addsign', '--define', '_gpg_name testuser', '--define', '_gpg_sign_cmd_extra_args --no-permission-warning --batch --passphrase=test123 --agent-program=/home/pokybuild/yocto-worker/oe-selftest/build/build-st-37321/tmp/work/core2-64-poky-linux/ncurses/6.1+20181013-r0/recipe- Dec 03 10:53:21 sysroot-native/usr/bin/gpg-agent|--auto-expand-secmem --pinentry-mode=loopback', '--define', '_binary_filedigest_algorithm 8', '--define', '__gpg /home/pokybuild/yocto-worker/oe-selftest/build/build-st-37321/tmp/work/core2-64-poky-linux/ncurses/6.1+20181013-r0/recipe-sysroot-native/usr/bin/gpg', '--define', '_gpg_path /tmp/oeqa-signing-00kspzxl', '/home/pokybuild/yocto-worker/oe-selftest/build/build-st-37321/tmp/work/core2-64-poky-linux/n Dec 03 10:53:21 curses/6.1+20181013-r0/deploy-rpms/core2_64/libpanel5-6.1+20181013-r0.core2_64.rpm']' returned non-zero exit status 255. Dec 03 10:59:08 hm how interesting, the disk space thing was on suse *agan* Dec 03 10:59:11 its always suse Dec 03 10:59:25 rburton: hmm, wonder why :/ Dec 03 10:59:58 stupid file system Dec 03 11:01:15 hm think i'm on the wrong builder Dec 03 11:09:15 RP: suse might be utilizing their filesystem snapshots technology? Dec 03 11:09:49 at least for me that caused inexplicable lack of space issues Dec 03 11:10:49 https://en.opensuse.org/openSUSE:Snapper_Tutorial Dec 03 11:15:14 everything but $home is btsfs and subvols on the suse builder Dec 03 11:19:12 kanavin: do we have to pass a value to that auto_expand to make it have an effect? Dec 03 11:20:12 RP: I don't think so. but I don't know how gpg source code evolved since I did that Dec 03 11:31:54 RP: did the selftest logging stuff change recently? Dec 03 11:33:10 rburton: some of it Dec 03 11:36:17 RP: can't start selftest here Dec 03 11:36:22 $ oe-selftest -r oelib.path Dec 03 11:36:28 FileNotFoundError: [Errno 2] No such file or directory: '/data/poky-tmp/selftest/log/oe-selftest-results-20181203113600.log' Dec 03 11:43:59 RP: hm, do we have any tests that do non-trivial work in setUp()? i'm seeing oelib/path.py's setUp called three times when its ran Dec 03 11:44:13 oh idiot boy, of course Dec 03 11:44:16 thats per-test not per-class Dec 03 11:44:19 ignore me :) Dec 03 11:44:24 * rburton refactors too Dec 03 11:53:11 RP: ah, du on btrfs reports 0 for directories Dec 03 11:53:30 for small images, no doubt that results in the sums going wrong Dec 03 11:56:44 RP: presumably this isn't breaking on every suse run either Dec 03 11:56:49 which is frustrating Dec 03 12:00:11 ok so what's the actual point of suse putting eg /usr/local and /var/opt in separate btrfs sub volumes Dec 03 12:04:13 rburton: right, others have worked :/ Dec 03 12:06:03 kanavin: it definitely takes a parameter but what the default behaviour is, not sure Dec 03 12:15:08 rburton: we should probably talk about -next, anything there you don't want to see merged? Dec 03 12:15:20 RP: that commit that just adds whitespace Dec 03 12:15:45 i have a working hypothesis for the suse thing btw Dec 03 12:16:15 tldr lets not do builds in /tmp because on that builder there's only 30G available, and if we're building multiple images at once that might actually fill up Dec 03 12:16:27 i did a test build in /tmp and filled the disk up in about ten minutes Dec 03 12:17:49 rburton: I'll merge the meson bbappend, recipeutils, ptest bits, u-a, python sdk, nfs-utils, musl and btrfs-tools ? Dec 03 12:17:57 rburton: the rest is still in the questionable camp Dec 03 12:18:14 rburton: that is entirely possible, we don't require large amounts of space for /tmp Dec 03 12:18:23 right Dec 03 12:18:23 rburton: do we monitor it with DISKMON? Dec 03 12:18:26 yes Dec 03 12:18:34 well, normal builds Dec 03 12:18:40 so if it ran out we would know Dec 03 12:18:43 and my build failed neatly Dec 03 12:18:52 but inside a esdk test, i could see that not working right Dec 03 12:18:53 ABORT,/tmp,10M,1K Dec 03 12:19:03 (from the AB) Dec 03 12:19:08 right Dec 03 12:19:09 rburton: true Dec 03 12:19:15 btrfs is a bit funny too Dec 03 12:19:22 yes :/ Dec 03 12:19:37 rburton: I'll merge those bits and then we can think about the others Dec 03 12:19:46 yes that's good Dec 03 12:21:12 rburton: torn on the 90s timeout for example. Tests do show bitbake taking an age to start in some builds :( Dec 03 12:21:24 inotify issues Dec 03 12:22:09 rburton: see what you think of https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/43/steps/7/logs/step2d Dec 03 12:22:38 Here R5 52383 1543709221.3835173 Dec 03 12:22:38 Here R6 52383 1543709231.9136107 Dec 03 12:22:48 10s :/ Dec 03 12:22:58 Here R2 52383 1543709190.1513233 Dec 03 12:22:58 Here R3 52383 1543709221.3785965 Dec 03 12:23:15 31s :/ Dec 03 12:35:25 RP: that g-o issue with multilib should be fixed now, I sent the patch Dec 03 12:37:43 kanavin: thanks! I'll queue it in the next next :) Dec 03 12:41:32 RP: I also got perl-sanity to the point where it could be given a spin on the AB when there's a bit of free cycles available Dec 03 12:43:44 kanavin: I saw that. Let me try a "quick" run of it Dec 03 12:45:45 kanavin: running Dec 03 12:55:36 RP: where can I see the outcomes? Dec 03 12:58:49 kanavin: https://autobuilder.yoctoproject.org/typhoon/#/console Dec 03 12:59:07 kanavin: specifically https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/17 Dec 03 12:59:18 kanavin: seems to be failing :( Dec 03 13:01:42 kanavin: dpkg-native configure Dec 03 13:14:47 Could anybody give me a hand with including this in the yocto build: https://github.com/seemoo-lab/nexmon? Dec 03 13:15:02 Specifically the raspberry pi bit Dec 03 13:19:31 la_croix: whoa, this is Makefile hell Dec 03 13:21:24 LetoThe2nd Yeah, that's what I thought :( Dec 03 13:21:39 It seems to be the only way to get the raspberry pi's wifi module to run in monitor mode, though Dec 03 13:22:17 la_croix: i'd rip out the bits i need and pour them into a custom build. probably less painful Dec 03 13:22:27 but thats my $.02, explicitly. Dec 03 13:22:38 LetoThe2nd Fair enough, I'll give it a go Dec 03 13:22:51 Since you're here, do you have any experience on running python through cron? Dec 03 13:23:10 nope. Dec 03 13:25:10 Okay Dec 03 13:25:54 la_croix: OTOH, concerning the python/cron thing. have your read http://www.catb.org/esr/faqs/smart-questions.html ? Dec 03 13:27:08 LetoThe2nd No, I haven't, but I have searched for a solution and implemented the suggestions, none of which have worked. Since they seemed to work on other distros, I thought this might be a yocto thing, so I decided to ask here Dec 03 13:29:00 la_croix: nah, what i meant is: if i answer yes or no, it is of no help to you. and nobody else who reads along feels addressed. the point is, if you are experiencing problems, then just ask about those exact problems. don't address anybody specifically, and don't use meta-questions like "is anybody seeing problems", or "has anybody ever...", because those are actually not the questions that you want an Dec 03 13:29:06 answer to. Dec 03 13:29:20 LetoThe2nd Oh, fair enough Dec 03 13:29:26 la_croix: :) Dec 03 13:31:08 la_croix: example. i can ask "how do i fix the message ttyS0 respawning too fast when booting a beaglebone black" or i can ask "has anybody here experience with BBB uarts" Dec 03 13:31:19 i think the difference is obvious. :) Dec 03 13:31:21 LetoThe2nd Good point Dec 03 13:31:22 :) Dec 03 13:31:32 Ok, here goes ;) Dec 03 13:31:46 Cronie running on yocto, cron succeeds for a 'vanilla' python script, but fails for a python script that invokes a subprocess. No error message as cronie doesn't seem to be logging anywhere. Script runs successfully if started manually. Suggestion has been to use full paths, so I have updated everything to use full paths, but still no luck Dec 03 13:34:08 la_croix: i'd try to enable logging in some way, or look at journalctl -u cronie, if you are kicking it off with systemd Dec 03 13:34:27 la_croix: and if you need env variables, then check those. its not only PATH that is not set. Dec 03 13:36:52 LetoThe2nd journalctl -u cronie is empty... Dec 03 13:37:00 The env variables might be a good point, though Dec 03 13:38:02 In fact, the cronie user doesn't exist. It runs stuff as another user. Having said that, journalctl -u otheruser is also empty Dec 03 13:38:45 la_croix: journalctl -u is not about users.... Dec 03 13:41:23 * la_croix does some googling Dec 03 13:41:30 Ok, still, it's empty Dec 03 13:43:06 my attempt would be good old printf debugging. Dec 03 13:43:39 la_croix: probably that $PATH isn't set inside the cron job Dec 03 13:43:51 LetoThe2nd Okay, I think I might have found something :) Dec 03 13:44:15 rburton Well, the only thing it's calling as a subprocess is arecord (part of alsa) and I've specified the full path Dec 03 13:44:47 But I have actually managed to find an error Dec 03 13:52:15 Hey hey. I found an issue where Valgrind doesn't compile properly when targeting the raspberry pi. (It runs, but doesn't give correct trace information). Should I file this bug with the meta-raspberrypi overlay, or openembedded? Dec 03 13:52:28 (when i compile the same version manually on the target, it works fine) Dec 03 13:55:44 kanavin: one trick for the perl-native thing would be to basically say "we're using the host perl' and add perl-native to ASSUME_PROVIDED Dec 03 13:56:04 though somewhat concerned that not being able to build perl-native at all might break for someone Dec 03 13:56:18 not aware of anyone using perl C modules at build time, but you never know Dec 03 13:56:34 kanavin: did you run the perl test suite on target with the new perl? Dec 03 13:56:52 rburton: libxml-parser-perl comes in native variant as well, so someone might be using that Dec 03 13:57:08 meta/recipes-multimedia/pulseaudio/pulseaudio.inc:DEPENDS += "speexdsp libxml-parser-perl-native libcap" Dec 03 13:57:10 rburton: I did not. there was enough build time issues to sort :) Dec 03 13:57:15 meta/recipes-devtools/intltool/intltool_0.51.0.bb:DEPENDS_class-native = "libxml-parser-perl-native gettext-n Dec 03 13:57:52 pretty sure the intltool one is still valid, we can check if pulse is still using it Dec 03 13:59:03 possibly from when pulse used intltool Dec 03 14:00:56 need to wait for pulse 13.x for the intltool dep to drop Dec 03 14:10:25 rburton: I am not sure how to solve the systemtap-native problem, can you help me out please? Dec 03 14:10:46 basically, try bitbake systemtap-native on akanavin/perl-sanity branch Dec 03 14:11:16 genereally, I set RDEPENDS_${PN}_class-native = "" in such cases, but here it does not work, and I have no idea why Dec 03 14:16:46 rburton, RP: who is the right person to ask about yocto-kernel-cache? Dec 03 14:17:15 my question is: I'd like to experiment with changing some things in there, what's the standard approach in doing so? Dec 03 14:18:04 fork to github and add a custom throwaway kernel recipe that refers to that? Dec 03 14:22:52 kanavin: impressive work on perl, nicely done Dec 03 14:23:06 i'm actually impressed anyone had the guts to work on that recipe at all, ever Dec 03 14:24:47 kergoth: thanks :) sadly, the autobuilder reveals a ton of failures still Dec 03 14:29:27 kanavin: zeddii Dec 03 15:13:26 hi Dec 03 15:13:43 I would like to avoid -dbg and -dev packages to be built Dec 03 15:13:57 so I added INHIBIT_PACKAGE_STRIP and INHIBIT_PACKAGE_DEBUG_SPLIT to my local.conf file Dec 03 15:14:08 but -dbg and -dev packages are still created Dec 03 15:14:26 didile: why do you want that? Dec 03 15:14:40 because it takes almost 2h to compile Dec 03 15:14:58 and I don't need debug packages Dec 03 15:15:17 didile: the 2 hours probably mostly go to something else that creation of those packages Dec 03 15:15:38 I'd say it's most likely compiler instances on a machine that has too few cpu cores Dec 03 15:16:19 ok but why is it still creating dbg packages when I explictly set to not create them? Dec 03 15:16:55 I've 8 cores Dec 03 15:17:53 It takes also a lot of useless disk space Dec 03 15:20:37 New news from stackoverflow: yocto project - missing dependencies in recipe-sysroot Dec 03 15:20:38 didile: it's not going to take any less time to compile, inhibiting packaging only affects packaging. Dec 03 15:22:37 kergoth: ok Dec 03 15:22:55 but yes, inhibit_package_debug_split should be working.. Dec 03 15:23:04 i'm stuck. any ideas on why this link is failing, not finding a "main" procedure in the libraries: https://paste.fedoraproject.org/paste/Qu9ViXLLhi7lbuIVPli6bw Dec 03 15:23:34 kergoth: I'm on morty Dec 03 15:23:48 arm-fslc-linux-gnueabi-g++ -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard --sysroot=/Storage/production-hardware-revision-A-1.0/sources/poky/build-hw-test-image/tmp/sysroots/imx6ul-var-dart -o /Storage/production-hardware-revision-A-1.0/sources/poky/build-hw-test-image/src/client-6300-devel/production-client-devel-1.0-rc0/app/client/wx-tree/dartyocto/wx-tree `wx-config --libs aui,html,adv,core,xml,base --version=3.0` Dec 03 15:23:58 nowhere in that line does it actually include any objects Dec 03 15:28:04 kergoth: details. Dec 03 15:28:06 :) Dec 03 15:30:14 doh! Dec 03 15:30:40 _I_ provide main. doh! DOH DOH DOH... Dec 03 15:30:53 indeed Dec 03 15:31:15 you can't just link the wx libs together by themselves and get something useful ;) Dec 03 15:34:48 didile: creating debug packages is just a matter of extracting the debug symbols from the binaries. its the compile that takes ages. *if* your debug symbols are *huge* then you can remove -g from CFLAGS to stop the debug symbols being generated in the first place, but i doubt you'll see a huge gain Dec 03 15:36:14 rburton: I see.. Dec 03 15:38:15 kanavin: I'm going to bet the problem is max locked memory (kbytes, -l) 16384 Dec 03 15:38:43 if you're just concerned about temporary disk space, use rm_work, Dec 03 15:40:04 kergoth: I already set RM_WORK Dec 03 15:40:48 I'm trying to get chromium-x11 building, and it's complaining about a missing gtk+3 header. Dec 03 15:40:48 ../../chrome/browser/ui/libgtkui/select_file_dialog_impl_gtk.cc:7:10: fatal error: gdk/gdkx.h: No such file or directory Dec 03 15:40:48 It is putting the gtk+3 sysroot into its include path. I can see that the header doesn't exist in the gtk+3 image. I'm wondering why it's missing. Dec 03 15:41:33 sounds like your gtk+ was built without x11 Dec 03 15:42:39 kanavin: i suspect there's actually one or two problems in that sea of red Dec 03 15:42:45 Interesting. What do I need to add to my gtk recipe to enable x11 support? Dec 03 15:43:26 cdgarren: well its on by default Dec 03 15:44:24 rburton: Ok. Maybe to add some information, I was able to build my image for a different machine succesfully. I changed machines to a new dev kit, and then I saw the error. Dec 03 15:44:50 i don't understand this QA issue I'm getting: https://paste.fedoraproject.org/paste/3ajJD0ySem7-38j~jfX7xA Dec 03 15:45:17 rburton: So I'm not sure why it's misconfigured somehow for this new machine. Dec 03 15:45:50 maybe the new BSP turns off x11? Dec 03 15:46:37 rburton: let me do a quick diff between the machine conf files. Dec 03 15:52:40 rburton: I'm not seeing anything obvious. **** BEGIN LOGGING AT Mon Dec 03 15:54:29 2018 Dec 03 15:54:30 i'd use bitbake -e to examine DISTRO_FEATURES and -e gtk+ to examine PACKAGECONFIG Dec 03 16:05:40 I think kernel-yocto.bbclass has a bug when used with KBUILD_DEFCONFIG and S=... is specified. do_kernel_metadata tries to locate the defconfig based on ${S}, but sources have been moved in do_unpack_append of kernel.bbclass, so it points to a non-existent dir Dec 03 16:17:45 why am i getting these warnings? https://paste.fedoraproject.org/paste/YIxuywnYD0NBp9q19~8stw Dec 03 16:18:35 these files are part of my svn repo, but not used for the build, so i suspect the warnings are irrelevent, but they're irritating. Dec 03 16:18:42 why is yocto complaining about them? Dec 03 16:18:51 (these files == *.el files) Dec 03 16:19:41 kergoth: can you elaborate on what I should be looking for? Dec 03 16:20:28 kergoth: When I urn bitbake -e gtk+3, I see this line: PACKAGECONFIG="opengl wayland glx" Dec 03 16:20:44 kergoth: So does that mean it's not configured for x11? Dec 03 16:26:44 yates: did someone explain the GNU_HASH error? Dec 03 16:28:20 cdgarren: that's correct. likely your distro is wayland, not x11. check DISTRO and DISTRO_FEATURES Dec 03 16:28:53 RP: huh my qa patch was missing a chunk Dec 03 16:28:55 * rburton curses Dec 03 16:31:26 RP: does the rebuild button on the AB rebuild the same *hash* or branch? Dec 03 16:31:44 ie if i update the branch and hit rebuild, will it do what i want? Dec 03 16:33:02 yates: if the message said "No GNU_HASH in the ELF binary /path/too/foo, didn't pass LDFLAGS?" would that help? Dec 03 16:42:08 kergoth: I'm using poky. It does havbe x11 in the list of DISTRO_FEATURES in the bitbake -e output. Dec 03 16:43:39 kergoth: Could enabling opengl have something to do with this? I think that's one difference when I changed machines. Dec 03 16:43:48 rburton: hash Dec 03 16:45:20 kergoth: This line for PACAKAGECONFIG pre-expansion value looks interesting: "${@bb.utils.filter('DISTRO_FEATURES', 'opengl wayland x11', d)} ${@bb.utils.contains('DISTRO_FEATURES', 'opengl x11', 'glx', '', d)}" Dec 03 16:52:21 \o/ Dec 03 16:52:26 works. Dec 03 16:52:49 my application which depends on wxWidgets 3.0.4 builds and works. Dec 03 16:52:59 kergoth: I think maybe I tracked it down. In one of freescales appends to gtk+3, they remove x11 from DISTRO_FEATURES if both wayland and x11 are present. Dec 03 16:53:20 kergoth: So is my real fix going to be remove wayland from my DISTRO_FEATURES Dec 03 16:53:40 kanavin: max locked memory (kbytes, -l) 64 Dec 03 16:54:01 halstead: I'm pretty sure we need to increase this on the AB workers as 64 will cause problems with gpg Dec 03 16:55:53 thanks everyone for answering my incessant, oft stupid questions ! Dec 03 16:56:47 especially rburton, RP, khem, LetoThe2nd, and others Dec 03 16:57:16 oh, sorry, and you too kergoth Dec 03 16:57:58 also smart is working nicely too Dec 03 17:03:34 cdgarren: ah, well spotted Dec 03 17:03:41 that's a bit odd Dec 03 17:05:48 kergoth: Yeah. I'm not sure why they put that there. Not a fan. Thanks for your help to track that down. Dec 03 17:06:16 np Dec 03 17:14:57 again, anyone know why am i getting these warnings? https://paste.fedoraproject.org/paste/YIxuywnYD0NBp9q19~8stw Dec 03 17:15:02 (it's cleanup time...) Dec 03 17:17:27 yates: it can't find a file you've listed in SRC_URI Dec 03 17:18:07 RP: my src uri is just the whole repository: SRC_URI = "svn://ebtronwsus/svn/SmartDisplaySoftware;module=${SVNMODULE};protocol=https;rev=2415;" Dec 03 17:19:23 i yocto is looking inside the repo files and it doesn't know what to do with .el files (emacs lisp)... just a guess though Dec 03 17:19:47 SVNMODULE = "tags/production-client-devel-1.0-rc0" Dec 03 17:21:48 s/i/i suspect/ Dec 03 17:25:22 is there a command to say "ignore all XYZ files in the src_uri?" Dec 03 17:25:37 src_glob = "*.el" ? Dec 03 17:30:01 yates: I think there is something else in SRC_URI to cause that warning Dec 03 17:44:24 yates: I think kergoth answered you very patiently, so he deserves thanks the most :) Dec 03 17:48:02 thanks kergoth - much appreciated Dec 03 17:48:47 np Dec 03 17:52:13 RP: http://errors.yoctoproject.org/Errors/Details/203013/ once builders updated to ubuntu 18.04 all builds are showing this error for freerdp do_packagedata Dec 03 17:58:43 khem: I commented yesterday, we don't see any problems like that on the YP 1804 builds Dec 03 17:58:58 khem: seems one of the versions is None which would be odd Dec 03 17:59:15 khem: musl/nfs-utils merged thanks :) Dec 03 18:00:28 RP: but you dont build freerdp I guess Dec 03 18:00:41 khem: no Dec 03 18:01:05 http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/freerdp/freerdp_git.bb?h=master#n11 Dec 03 18:01:17 I wonder if using GITPKGVTAG is an issue Dec 03 18:01:56 khem: gitpkgv was my guess Dec 03 18:02:15 I wonder if we need to use it here Dec 03 18:02:15 khem: newer version of git with different output? Dec 03 18:02:29 yeah its possible. Dec 03 18:02:30 * RP wishes we could have the fetcher do what people need Dec 03 18:03:27 Did you break the fetcher again? Dec 03 18:04:16 Crofton: all selftests pass so its perfect ;-) Dec 03 18:04:53 usbmuxd libusbmuxd libinih also uses GITPKGVTAG and they build fine Dec 03 18:05:01 heh Dec 03 18:05:29 I suggest watching this: https://www.spacex.com/webcast Dec 03 18:17:47 Crofton: I second that Dec 03 18:20:55 lol Dec 03 18:21:02 How many zynqs aboard? Dec 03 18:21:46 not enough, just enough or too many? Dec 03 18:22:18 Crofton: hahaha Dec 03 18:23:04 khem, I am building freerdp on ubuntu 18.04 as we chat Dec 03 18:24:44 ant_home: my situation is a bit different where the buildhistory is same as it was before upgrading 16.04 -> 18.04 Dec 03 18:24:46 I have a week-old oe-core checkout Dec 03 18:24:51 so its not a clean build Dec 03 18:24:57 argh Dec 03 18:30:02 no issues here Dec 03 18:30:36 bbl Dec 03 18:43:10 no booms Dec 03 19:19:25 hi guys, i'm trying to upgrade my image from branch sumo to branch thud, but when the image is built, there is no network interfaces on it Dec 03 19:20:39 something changed in the kernel customizing stuffs? Dec 03 19:41:18 Crofton: they made that landing look easy Dec 03 19:42:52 yeah Dec 03 19:43:10 hi, i'm trying to upgrade my layer from sumo to thud, but the image built on thud has no network interfaces Dec 03 19:43:20 someone knows if there is any change on kernel customization? Dec 03 19:43:49 the number of chances from sumo to thud is massive, as is true of any major releases Dec 03 19:45:03 i'm asking because I created a custom distro and custom machine based on generic-x86-64 Dec 03 19:45:12 shurelous__: are you using systemd? Dec 03 19:45:18 yes Dec 03 19:46:05 I used to bbappend linux-yocto recipe by adding include bsp/common-pc-64/common-pc-64-standard.scc nopatch Dec 03 19:46:05 so I don't know if it was a change, but I did notice recently that if I built a systemd-based image we don't install a network config file for systemd-networkd and the result is no network interfaces get brought up by default Dec 03 19:46:30 humm... Dec 03 19:46:49 shurelous__: pastebin your dmesg Dec 03 19:46:57 i wonder how my nuc has working network then Dec 03 19:47:06 maybe networkd does nothing and the netbase init files still work Dec 03 19:47:08 there's some coverage of config here that helped me: https://wiki.archlinux.org/index.php/systemd-networkd Dec 03 19:47:30 rburton: maybe... it's not guaranteed that those will be in an image, maybe they are in your case Dec 03 19:48:06 I made a comment on our "default to systemd" bug for 2.7 about this, perhaps I should file an actual bug Dec 03 19:48:42 hmm, true. we probably should rethink the default network handling on images lacking connman, etc. use netbase, networkd, or even systemctl enable dhcpcd@. something.. Dec 03 19:49:49 ah yes that would be it, i most likely have connman Dec 03 19:49:54 (for clarification, /etc/network/interfaces is not guaranteed to be in a systemd image because it's installed as part of init-ifupdown) Dec 03 19:50:14 I'll file a bug Dec 03 19:52:15 marka: I cant paste it because my image has no mouse integration, and I cant select the text to paste it, I can only take prints from it Dec 03 19:54:49 bluelightning: easiest would be a config that just turns on dhcp for en*, and let people bbappend their own file Dec 03 19:55:05 shurelous__: ah, there are ways but don't worry about it. Is there any signs of life of any eth* in the dmesg? What about 'ip l sh' output? or '/sys/devices'? Dec 03 19:55:23 bluelightning: thank you sir for the tip, I will try configuring my network here. Dec 03 19:55:40 yes Dec 03 19:55:41 rburton: right, that would be a good start Dec 03 19:55:57 the network driver recognized the two interfaces Dec 03 19:56:05 eth0 and eth1 Dec 03 19:56:42 e1000 0000:00:03.0 eth0:(PCI:33MHz:32-bit)... Dec 03 19:57:48 but there is no message saying that the link is up or down, just the messages from the network driver Dec 03 19:58:05 shurelous: you can rule out kernel changes then at this point pretty much Dec 03 19:59:42 with systemd it will rename eth* to use "predictable" names, ie. enp0s3 or similar Dec 03 19:59:55 bluelightning: my /etc/network/interfaces is configured and the systemd-networkd service is running Dec 03 20:00:06 and you will want to setup /etc/systemd/networkd/* files Dec 03 20:00:33 I disabled the unpredictable names Dec 03 20:00:58 shurelous: that will be your fun, I tend not to fight systemd Dec 03 20:00:59 humm, so systemd dont use the /etc/network/interfaces configuration? Dec 03 20:01:07 either go all the way or no way at all Dec 03 20:01:16 hahah Dec 03 20:01:38 shitty, I hate systemd as much as anyone, but don't do 1/2 measures Dec 03 20:01:42 filed: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13057 Dec 03 20:01:43 Bug 13057: normal, Undecided, ---, ross.burton, NEW , No default network configuration for systemd-networkd Dec 03 20:02:28 ok, I will remove my custom change and configure my networkd files Dec 03 20:02:55 thank you folks, if it works I come back here to explain how I solved Dec 03 20:02:59 sounds good. I just wanted to make sure the kernel bits were working fine Dec 03 20:03:03 and it appears they are Dec 03 20:03:29 we didn't change the kernel configuration or such that should have caused any major behavior change Dec 03 20:04:04 the path /etc/systemd/networkd even exists here in my image Dec 03 20:04:14 shoud be this the problem hehehe Dec 03 20:07:42 Worked Dec 03 20:08:24 I had to create a /etc/systemd/network/20-foo.network Dec 03 20:18:07 shurelous_: see https://github.com/YoeDistro/meta-yoe/tree/master/recipes-core/systemd Dec 03 20:18:20 yoe distro takes care of such things automatically once you choose systemd Dec 03 20:18:53 thank you khem Dec 04 01:11:24 Getting this weird error with running bitbake using Icecream, I got both my config and the error in this gist: https://gist.github.com/junland/d932bd63ca2c871b99e64eda543ca2fe Dec 04 01:14:54 wait maybe it has todo with this create icecc env script thing. hm Dec 04 01:38:04 After sourcing the environment of the sdk and typing "make myfile.c" , I get the message "Nothing to do". I removed the binary and repeated agaion. Why is it not working? Dec 04 01:55:14 learningc: make operates on a Makefile, do you have a Makefile in your project ? Dec 04 02:01:09 Apparently, there is a way to use make without a makefile when using the sdk Dec 04 02:01:56 See this page: https://github.com/gumstix/yocto-manifest/wiki/Cross-Compile-with-Yocto-SDK Dec 04 02:07:52 learningc: yes you can do one offs so say if you want to compile foo.c into a binary you could do 'make foo' in same dir as foo.c Dec 04 02:09:07 khem, I used to get it to work before. But somehow it got broken and I'm not sure why. Dec 04 02:09:31 How can I get it to work again? Dec 04 02:10:52 I want to use this method to create some one off tests of apis Dec 04 02:13:18 Ah! I did not notice that I should not write the filename with .c. I removed .c and now works Dec 04 02:29:24 Is there something that would affect the setting / resolution of our clock timers? Dec 04 02:29:55 When running our image in VirtualBox, /proc/timer_list shows 1 ns resolutions. Dec 04 02:30:30 when running on hardware, latest atom, we are seeing .resolution: 1000000 nsecs Dec 04 02:30:52 atom = e3950 Dec 04 02:54:59 I have a shared library binary that I would like to use with the sdk create with Yocto. Is it sufficient to just copy mylib.so to my sdk sysroot/usr/lib/ folder? **** ENDING LOGGING AT Tue Dec 04 03:00:15 2018